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CHAPTER  1 


INTRODUCTION 


The  Ada  iapleaentation  described  above  was  tested  according  to  the 
Ada  Validation  Procedures  [Pro92]  against  the  Ada  Standard  [Ada83] 
using  the  current  Ada  Conpller  Validation  Capability  (ACVC) .  This 
Validation  Sussary  Report  (VSR)  gives  an  account  of  the  testing  of 
this  Ada  iapleatentation.  For  any  technical  tens  used  in  this 
report,  the  reader  is  referred  to  [Pro92].  A  detailed  description 
of  the  ACVC  say  be  found  in  the  current  ACVC  User ' s  Guide  [UG89 ] . 


1.1  USE  OF  THIS  VALIDATION  SUMMARY  REPORT 

Consistent  with  the  national  laws  of  the  originating  country,  the 
Ada  Certification  Body  say  make  full  and  free  public  disclosure  of 
this  report.  In  the  United  States,  this  is  provided  in  accordance 
with  the  "Freedom  of  Information  Act"  (5  U.S.C.  #552).  The  results 
of  this  validation  apply  only  to  the  computers,  operating  systems, 
and  compiler  versions  identified  in  this  report. 

The  organizations  represented  on  the  signature  page  of  this  report 
do  not  represent  or  warrant  that  all  statements  set  forth  in  this 
report  are  accurate  and  complete,  or  that  the  subject 
implementation  has  no  nonconformities  to  the  Ada  Standard  other 
than  those  presented.  Copies  of  this  report  are  available  to  the 
public  from  the  AVF  which  performed  this  validation  or  from: 

National  Technical  Information  Service 
5285  Port  Royal  Road 
Springfield,  Virginia  22161 
U.S.A. 

Questions  regarding  this  report  or  the  validation  test  results 
should  be  directed  to  the  AVF  tdiich  performed  this  validation  or 
to: 


Ada  Validation  Organization 

Computer  and  Software  Engineering  Division 

Institute  for  Defense  Analyses 

1801  North  Beauregard  Street 

Alexandria,  Virginia  22311-1772 

U.S.A. 
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1 . 2  REFERENCES 


[Ada83]  BfiteEfiPgS — Mflnvifll £llfi Ada  Programming Language . 

ANSI/MIL-STD-1815A,  February  1983  and  ISO  8652-1987. 

[Pro92]  Ada  Compiler  Validation  Procedures.  Version  3.1,  Ada  Joint 
Program  Office,  August  1992. 

[UG89]  Ada  Compiler  Validation  Capability  User's  Guide.  21  June 
1989. 


1.3  ACVC  TEST  CLASSES 

Compliance  of  Ada  implementations  is  tested  by  means  of  the  ACVC. 
The -ACVC  contains  a  collection  of  test  programs  structured  into  six 
test  classes:  A,  B,  C,  0,  E,  and  L.  The  first  letter  of  a  test 
name  identifies  the  class  to  which  it  belongs.  Class  A,  C,  D,  and 
E  tests  are  executable.  Class  B  and  class  L  tests  are  expected  to 
produce  errors  at  compile  time  and  link  time,  respectively. 

The  executable  tests  are  %n:itten  in  a  self -checking  manner  and 
produce  a  PASSED,  FAILED,  or  NOT  APPLICABLE  message  indicating  the 
result  when  they  are  executed.  Three  Ada  library  units,  the 
packages  REPORT  and  SPPRT13,  and  the  procedure  CHECK  FILE  are  used 
for  this  purpose.  The  package  REPORT  also  provides  a  set  of 
identity  functions  used  to  defeat  some  compiler  optimizations 
allowed  by  the  Ada  Standard  that  would  circumvent  a  test  objective. 
The  package  SPPRT13  is  used  by  many  tests  for  Chapter  13  of  the  Ada 
Standard.  The  procedure  CHECK_FILE  is  used  to  check  the  contents 
of  text  files  written  by  some  of  the  Class  C  tests  for  Chapter  14 
of  the  Ada  Standard.  The  operation  of  REPORT  and  CHECK_FILE  is 
checked  by  a  set  of  executable  tests.  If  these  units  are  not 
operating  correctly,  validation  testing  is  discontinued. 

Class  B  tests  check  that  a  compiler  detects  illegal  language  usage. 
Class  B  tests  are  not  executable.  Each  test  in  this  class  is 
compiled  and  the  resulting  compilation  listing  is  examined  to 
verify  that  all  violations  of  the  Ada  Standard  are  detected.  Some 
of  the  class  B  tests  contain  legal  Ada  code  which  must  not  be 
flagged  illegal  by  the  compiler.  This  behavior  is  also  verified. 

Class  L  tests  check  that  an  Ada  implementation  correctly  detects 
violation  of  the  Ada  Standard  involving  multiple,  separately 
compiled  units.  Errors  are  expected  at  link  time,  and  execution  is 
attempted . 

In  some  tests  of  the  ACVC,  certain  macro  strings  have  to  be 
replaced  by  implementation-specific  values— for  example,  the 
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largest  integer.  A  list  of  the  values  used  for  this  implementation 
is  provided  in  Appendix  A.  In  addition  to  these  anticipated  test 
modifications,  additional  changes  may  be  required  to  remove 
unforeseen  conflicts  between  the  tests  and  implementation-dependent 
characteristics.  The  modifications  required  for  this 
implementation  are  described  in  section  2.3. 

For  each  Ada  implementation,  a  customized  test  suite  is  produced  by 
the  AVF.  This  customization  consists  of  making  the  modifications 
described  in  the  preceding  paragraph,  removing  withdra%m  tests  (see 
section  2.1)  and,  possibly  some  inapplicable  tests  (see  Section  3.2 
and  (UG89]). 

In  order  to  pass  an  ACVC  an  Ada  implementation  must  process  each 
test  of  the  customized  test  suite  according  to  the  Ada  Standard. 


1.4  DEFINITION  OF  TERMS 


Ada  Compiler  The  software  and  any  needed  hardware  that 

have  to  be  added  to  a  given  host  and  target 
computer  system  to  allow  transformation  of 
Ada  programs  into  executable  form  and 
execution  thereof. 

The  means  for  testing  compliance  of  Ada 
implementations.  Validation  consisting  of 
the  test  suite,  the  support  programs,  the 
ACVC  Capability  User’s  Guide  and  the 
template  for  the  validation  summary  (ACVC) 
report. 

Ada  Implementation  An  Ada  compiler  with  its  host  computer 

system  and  its  target  computer  system. 

Ada  Joint  Program  The  part  of  the  certification  body  which 

Office  (AJPO)  provides  policy  and  guidance  for  the  Ada 

certification  Office  system. 

Ada  Validation  The  part  of  the  certification  body  which 

Facility  (AVF)  carries  out  the  procedures  required  to 

establish  the  compliance  of  an  Ada 
implementation. 

Ada  Validation  The  part  of  the  certification  body  that 

Organization  (AVO)  provides  technical  guidance  for  operations 

of  the  Ada  certification  system. 

Compliance  of  an  The  ability  of  the  implementation  to  pass  an 

Ada  Implementation  ACVC  version. 


Ada  Compiler 
Validation 
Capability  (ACVC) 
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Computer  System 


Conformity 

Customer 

Declaration  of 
Conformance 

Host  Computer 
System 

Inapplicable  Test 

ISO 

LRM 

Operating  System 

Target  Computer 
System 


A  functional  unit,  consisting  of  one  or  more 
computers  and  associated  software,  that  uses 
common  storage  for  all  or  part  of  a  program 
and  also  for  all  or  part  of  the  data 
necessary  for  the  execution  of  the  program; 
executes  user*  written  or  user-designated 
programs;  performs  user-designated  data 
manipulation,  including  arithmetic 
operations  and  logic  operations;  and  that 
can  execute  programs  that  modify  themselves 
during  execution.  A  computer  system  may  be  a 
stand-alone  vmit  or  may  consist  of  several 
inter-connected  units. 

Fulfillment  by  a  product,  process,  or 
service  of  all  requirements  specified. 

An  individual  or  corporate  entity  who  enters 
into  an  agreement  with  an  AVF  which 
specifies  the  terms  and  conditions  for  AVF 
services  (of  any  kind)  to  be  performed. 

A  formal  statement  from  a  customer  assuring 
that  conformity  is  realized  or  attainable  on 
the  Ada  implementation  for  which  validation 
status  is  realized. 

A  computer  system  where  Ada  source  programs 
are  transformed  into  executable  form. 

A  test  that  contains  one  or  more  test 
objectives  found  to  be  irrelevant  for  the 
given  Ada  implementation. 

International  Organization  for 
Standardization. 

The  Ada  standard,  or  Language  Reference 
Manual,  published  as  ANSI/MIL-STD-1615A 
-1983  and  ISO  8652-1987.  Citations  from  the 
LRM  take  the  form  ''<section>.<subsection>: 
<paragraph>.  ** 

Software  that  controls  the  execution  of 
programs  and  that  provides  services  such  as 
resource  allocation,  scheduling, 
input/output  control,  and  data  management. 
Usually,  operating  systems  are  predominantly 
software,  but  partial  or  complete  hardware 
implementations  are  possible. 

A  computer  system  where  the  executable  form 
of  Ada  programs  are  executed. 
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Validated  Ada 
Compiler 

Validated  Ada 
Implementation 

Validation 


Withdrawn  Test 


The  compiler  of  a  validated  Ada 
implementation . 

An  Ada  implementation  that  has  been 
validated  successfully  either  by  AVF  testing 
or  by  registration  [Pro92]. 

The  process  of  checking  the  conformity  of  an 
Ada  compiler  to  the  Ada  programming  language 
and  of  issuing  a  certificate  for  this 
implementation. 

A  test  found  to  be  incorrect  and  not  used  in 
conformity  testing.  A  test  may  be  incorrect 
because  it  has  an  invalid  test  objective, 
fails  to  meet  its  test  objective,  or 
contains  erroneous  or  illegal  use  of  the  Ada 
programming  language. 
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CHAPTER  2 


IMPLEMENTATION  DEPENDENCIES 


2 . 1  WITHDRAWN  TESTS 

Some  tests  are  withdrawn  by  the  AVO  from  the  ACVC  because  they  do 
not  conform  to  the  Ada  Standard.  The  following  104  tests  had  been 
withdrawn  by  the  Ada  Validation  Organization  (AVO)  at  the  time  of 
validation  testing.  The  rationale  for  withdrawing  each  test  is 
available  from  either  the  AVO  or  the  AVF.  The  publication  date  for 
this  list  of  withdrawn  tests  is  93-11-22. 


B27005A 

E28005C 

B28006C 

C32203A 

C34006D 

C35507K 

C35507L 

C35507N 

C355070 

C35507P 

C35508I 

C35508J 

C35508M 

C35508N 

C35702A 

C35702B 

C37310A 

B41308B 

C43004A 

C45114A 

C45346A 

C45612A 

C45612B 

C45612C 

C45651A 

C46022A 

B49008A 

B49008B 

A54B02A 

C55B06A 

A74006A 

C74308A 

B83022B 

B83022H 

B83025B 

B83025D 

B83026B 

C83026A 

C83041A 

B85001L 

C86001F 

C94021A 

C97116A 

C98003B 

BA2011A 

CB7001A 

CB7001B 

CB7004A 

CC1223A 

BC1226A 

CC1226B 

BC3009B 

BD1B02B 

BD1B06A 

AD1B08A 

BD2A02A 

CD2A21E 

CD2A23E 

CD2A32A 

CD2A41A 

CD2A41E 

CD2A87A 

CD2B15C 

BD3006A 

BD4008A 

CD4022A 

CD4022D 

CD4024B 

CD4024C 

CD4024D 

CD4031A 

CD4051D 

C05111A 

CD7004C 

ED7005D 

CD7005E 

AD7006A 

CD7006E 

AD7201A 

AD7201E 

CD7204B 

AD7206A 

BD8002A 

BD8004C 

CD9005A 

CD9005B 

CDA201E 

CE2107I 

CE2117A 

CE2117B 

CE2119B 

CE2205B 

CE2405A 

CE3111C 

CE3116A 

CE3118A 

CE3411B 

CE3412B 

CE3607B 

CE3607C 

CE3607D 

CE3812A 

CE3814A 

CE3902B 

2 . 2  INAPPLICABLE  TESTS 

A  test  is  inapplicable  if  it  contains  test  objectives  which  are 
Irrelevant  for  a  given  Ada  implementation.  The  inapplicability 
criteria  for  some  tests  are  explained  in  documents  issued  by  ISO 
and  the  AJPO  known  as  Ada  Commentaries  and  commonly  referenced  in 
the  format  Al-ddddd.  For  this  Implementation,  the  following  tests 
were  determined  to  be  inapplicable  for  the  reasons  indicated; 
references  to  Ada  Commentaries  are  Included  as  appropriate. 

The  following  201  tests  have  floating-point  type  declarations 
requiring  more  digits  than  sySTEM.MAX_DIGITS: 

C24113L. .Y  (14  tests)  C35705L. .Y  (14  tests) 

C35706L..Y  (14  tests)  C35707L. .Y  (14  tests) 
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C35708L. .Y 

(14 

tests) 

C35802L. .Z 

(15 

tests) 

C45241L. .Y 

(14 

tests) 

C45321L. .Y 

(14 

tests) 

C45421L. .Y 

(14 

tests) 

C45521L. .Z 

(15 

tests) 

C45524L. .Z 

(15 

tests) 

C45621L. .Z 

(15 

tests) 

C45641L. .Y 

(14 

tests) 

C46012L. .Z 

(15 

tests) 

C24113I..K  (3  tests)  use  a  line  length  in  the  input  file  which 
exceeds  126  characters. 

C35404D,  C45231D,  B86001X,  C86006E,  and  C07101G  check  for  a 
predefined  integer  type  with  a  naee  other  than  INTEGER, 
LONG_INTEGER,  or  SHORT_INTEGER;  for  this  iapleaentation,  there  is 
no  such  type. 

C35713B,  C45423B,  B86001T,  and  C86006H  check  for  the  predefined 
type  SHORT_PI/>AT ;  for  this  iepleaentation,  there  is  no  such  type. 

C35713D  and  B86001Z  check  for  a  predefined  floating*-point  type  with 
a  nane  other  than  FLOAT,  LONG_PLOAT,  or  SHORT_rLOAT;  for  this 
implementation,  there  is  no  such  type. 

C45531M..P  and  C45532H..P  (8  tests)  check  fixed-point  operations 
for  types  that  require  a  SYSTEM. MAX  MANTISSA  of  47  or  greater;  for 
this  implementation,  MAX_MANTISSA  fs  less  than  47. 

C45624A..B  (2  tests)  check  that  the  proper  exception  is  raised  if 
MACHINE_OVERFLOWS  is  FALSE  for  floating  point  types  and  the  results 
of  various  floating-point  operations  lie  outside  the  range  of  the 
base  type;  for  this  implementation,  MACHINE_OVERFLOWS  is  TRUE. 

C4A013B  contains  a  static  universal  real  expression  that  exceeds 
the  range  of  this  implementation's  largest  floating-point  type; 
this  expression  is  rejected  by  the  compiler. 

056001B  uses  65  levels  of  block  nesting;  this  level  of  block 
nesting  exceeds  the  capacity  of  the  compiler. 

B8600iy  uses  the  name  of  a  predefined  fixed-point  type  other  than 
type  DURATION;  for  this  implementation,  there  is  no  such  type. 

C96005B  uses  values  of  type  DURATION'S  base  type  that  are  outside 
the  range  of  type  DURATION;  for  this  implementation,  the  ranges  are 
the  same. 

CA2009C  and  CA2009F  check  whether  a  generic  unit  can  be 
instantiated  before  its  body  (and  any  of  its  siibunits)  is  compiled; 
this  implementation  creates  a  dependence  on  generic  units  as 
allowed  by  AI-00408  and  AI-00506  such  that  the  compilation  of  the 
generic  unit  bodies  makes  the  instantiating  units  obsolete.  (See 
section  2.3.) 
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CD1009C  checks  whether  a  length  clause  can  specify  a  non-default 
size  for  a  floating-point  type;  this  inpleaentation  does  not 
support  such  sizes. 

C02A84h,  C02A84E,  C02A84I..J  (2  tests),  and  CD2A840  use  length 
clauses  to  specify  non-default  sizes  for  access  types;  this 
isplesentation  does  not  support  such  sizes. 

The  following  264  tests  check  operations  on  sequential,  text,  and 
direct  access  files;  this  isplesentation  does  not  support  external 
files: 


CE2102A. .C 

(3) 

CE2102G. .H 

(2) 

CE2102K 

CE2102N..Y  1 

(12) 

CE2103C. .D 

(2) 

CE2104A. .D 

(4) 

CE2105A. .B 

(2) 

CE2106A. .B 

(2) 

CE2107A. .H 

(8) 

CE2107L 

CE2108A. .H 

(8) 

CE2109A..C 

(3) 

CE2110A. .D 

(4) 

CE2111A. .1 

(9) 

CE2115A. .B 

(2) 

CE2120A. .B 

(2) 

CZ2201A. .C 

(3) 

EE2201D. .E 

(2) 

CE2201F. .N 

(9) 

CE2203A 

CE2204A. .D 

(4) 

CE2205A 

CE2206A 

CE2208B 

CE2401A. .C 

(3) 

EE24010 

CE2401E. .F 

(2) 

EE2401G 

CE2401H. .L 

(5) 

CE2403A 

CE2404A. .B 

(2) 

CE2405B 

CE2406A 

CE2407A. .B 

(2) 

CE2408A. .B 

(2) 

CE2409A. .B 

(2) 

CE2410A. .B 

(2) 

CE2411A 

CE3102A. .C 

(3) 

CE3102F. .H 

(3) 

CE3102J. .K 

(2) 

CE3103A 

CE3104A. .C 

(3) 

CE3106A. .B 

(2) 

CE3107B 

CE3108A. .B 

(2) 

CE3109A 

CE3110A 

CE3111A. .B 

(2) 

CE31110. .E 

(2) 

CE3112A. .D 

(4) 

CE3114A. .B 

(2) 

CE3115A 

CE3119A 

EE3203A 

EE3204A 

CE3207A 

CE3208A 

CE3301A 

EE3301B 

CE3302A 

CE3304A 

CE3305A 

CE3401A 

CE3402A 

EE3402B 

CE3402C. .D 

(2) 

CE3403A. .C 

(3) 

CE3403E. .F 

(2) 

CE3404B.  .0 

(3) 

CE3405A 

EE3405B 

CE3405C. .D 

(2) 

CE3406A. .D 

(4) 

CE3407A. .C 

(3) 

CE3408A. .C 

(3) 

CE3409A 

CE3409C. .E 

(3) 

EE3409F 

CE3410A 

CE3410C. .E 

(3) 

EE3410F 

CE3411A 

CE3411C 

CE3412A 

EE3412C 

CE3413A. .C 

(3) 

CE3414A 

CE3602A. .0 

(4) 

CE3603A 

CE3604A. .B 

(2) 

CE3605A. .E 

(5) 

CE3606A. .B 

(2) 

CE3704A. .F 

(6) 

CE3704M. .0 

(3) 

CE3705A. .E 

(5) 

CE37060 

CE3706F. .0 

(2) 

CE3804A. .P 

(16) 

CE3805A. .B 

(2) 

CE3806A. .B 

(2) 

CE3B06D. .E 

(2) 

CE3806G. .H 

(2) 

CE3904A. .B 

(2) 

CE3905A. .C 

(3) 

CE3905L 

CE3906A. .C 

(3) 

CE3906E. .F 

(2) 

CC2103A,  CE2103B,  and  CE3107A  use  an  illegal  file  nase  in  an 

attespt  to  create  a  file  and  expect  NAME_CRROR  to  be  raised;  this 
isplesentation  does  not  support  external  files  and  so  raises 
USE_CRROR.  (See  section  2.3.) 

2.3  TEST  MODIFICATIONS 

Modifications  (see  section  1.3)  were  required  for  71  tests. 

The  following  tests  were  split  into  two  or  sore  tests  because  this 
isplesentation  did  not  report  the  violations  of  the  Ada  Standard  in 
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the  way  expected  by  the  original  tests. 


B22003A  B26001A 
B35101A  B37106A 
B38009B  B55A01A 
B61001R  B61001W 
B83E010  B83E01E 
B91002C  B91002D 
B91002J  B91002K 
B95077A  B97103E 
BC1109D  BC1202A 


B26002A 

B37301B 

B61001C 

B67001H 

B85001D 

B91002E 

B91002L 

B97104G 

BC1202F 


B26005A 

B37302A 

B61001F 

B83A07A 

B850080 

B91002P 

B95030A 

BAIOOIA 

BC1202G 


B28003A 

B38003A 

B61001H 

B83A07B 

B91001A 

B91002G 

B95061A 

BAllOlB 

BE2210A 


B29001A 

B38003B 

B61001I 

B83A07C 

B91002A 

B91002H 

B95061F 

BC1109A 

BE2413A 


B33301B 

B38009A 

B61001H 

B83E01C 

B91002B 

B91002I 

B95061G 

BC1109C 


C83030C  and  C86007A  were  graded  passed  by  Test  Modification  as 
directed  by  the  AVO.  These  tests  were  sodlfied-  by  inserting 
"PRAGMA  ELABORATE  (REPORT);"  before  the  pac)cage  declarations  at 
lines  13  and  11,  respectively,  without  the  pragma,  the  packages 
may  be  elaborated  prior  to  pac)cage  Report's  body,  and  thus  the 
packages'  calls  to  function  REPOm'.IDENT_INT  at  lines  14  and  13, 
respectively,  will  raise  PROGRAM_ERROR. 

CA2009C  and  CA2009F  were  graded  inapplicable  by  Evaluation 
Modification  as  directed  by  the  AVO.  These  tests  contain 
instantiations  of  a  generic  unit  prior  to  the  compilation  of  that 
unit's  body;  as  allowed  by  AI-00408  and  AI~00506,  the  compilation 
of  the  generic  unit  bodies  makes  the  compilation  unit  that  contains 
the  instantiations  obsolete. 

BC3204C  and  BC32050  were  graded  passed  by  Processing  Modification 
as  directed  by  the  AVO.  These  tests  check  that  Instantiations  of 
generic  units  with  unconstrained  types  as  generic  actual  parameters 
are  Illegal  if  the  generic  bodies  contain  uses  of  the  types  that 
require  a  constraint.  However,  the  generic  bodies  are  compiled 
after  the  units  that  contain  the  instantiations,  and  this 
implementation  creates  a  dependence  of  the  Instantiating  units  on 
the  generic  units  as  allowed  by  AI-00408  and  AI-00506  such  that  the 
compilation  of  the  generic  bodies  makes  the  instantiating  units 
obsolete — no  errors  are  detected.  The  processing  of  these  tests 
was  modified  by  re-compiling  the  obsolete  units;  all  intended 
errors  were  then  detected  by  the  compiler. 

CE2103A,  CE2103B,  and  CE3107A  were  graded  inapplicable  by 
Evaluation  Modification  as  directed  by  the  AVO.  The  tests  abort 
with  an  unhandled  exception  when  USE  ERROR  is  raised  on  the  attempt 
to  create  an  external  file.  This  Ts  acceptable  behavior  because 
this  implementation  does  not  support  external  files  (cf .  AI-00332) . 
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CHAPTER  3 


PROCESSING  INFORMATION 


3 . 1  TESTING  ENVIRONMENT 

Th«  Ada  iaplaaentation  tested  in  this  validation  effort  is 
described  adequately  by  the  information  given  in  the  initial  pages 
of  this  report. 

For  technical  information  about  this  Ada  iaqplementation,  contact: 

Forrest  Holemon 

410  North  44th  Street,  Suite  320 
Phoenix,  Arizona  85008  (U.S.A.) 

Telephone:  602-275-7172 
Telefax:  602-275-7502 

For  sales  information  about  this  Ada  implementation,  contact: 

Mike  Halpin 

410  North  44th  Street,  Suite  320 
Phoenix,  Arizona  85008  S.A.) 

Telephone:  602-275-71*  2 
Telefax:  602-275-7502 

Testing  of  this  Ada  implementation  was  conducted  at  the  customer's 
site  by  a  validation  team  from  the  AVF. 

3.2  SUMMARY  OF  TEST  RESULTS 

An  Ada  Implementation  passes  a  given  ACVC  version  if  it  processes 
each  test  of  the  customized  test  suite  in  accordance  with  the  Ada 
Programming  Language  Standard,  whether  the  test  is  applicable  or 
inapplicable;  otherwise,  the  Ada  Implementation  fails  the  ACVC 
[Pro92] . 

For  all  processed  tests  (inapplicable  and  applicable),  a  result  was 
obtained  that  conforms  to  the  Ada  Programming  Language  Standard. 

The  list  of  items  below  gives  the  number  of  ACVC  tests  in  various 
categories.  All  tests  were  processed,  except  those  that  were 
withdrawn  because  of  test  errors  (item  b;  see  section  2.1),  those 
that  require  a  floating-point  precision  that  exceeds  the 
implementation's  maximum  precision  (item  e;  see  section  2.2),  and 
those  that  depend  on  the  support  of  a  file  system— if  none  is 
supported  (item  d) .  All  tests  passed,  except  those  that  are  listed 
in  sections  2.1  and  2.2  (counted  in  items  b  and  f,  below). 
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a)  Total  Niinber  of  Applicable  Tests 


3562 


b)  Total  Number  of  Withdra%m  Tests  104 

c)  Processed  Inapplicable  Tests  504 

d)  Non-Processed  I/O  Tests  0 

e)  Non-Processed  Floating-Point 

Precision  Tests  0 


f)  Total  Number  of  Inapplicable  Tests  504  (c4^-t>e) 

g)  Total  Nximber  of  Tests  for  ACVC  1.11  4170  (a-fb+f) 


3 . 3  TEST  EXECUTION 

A  magnetic  tape  containing  the  customized  test  suite  a  section 
1.3)  was  taken  on-site  by  the  validation  team  for  proce£»sing.  The 
contents  of  the  magnetic  tape  were  loaded  directly  onto  the  host 
computer. 

After  the  test  files  were  loaded  onto  the  host  computer,  the  full 
set  of  tests  was  processed  by  the  Ada  implementation.  The  DDC-I 
Ada  downloader  runs  on  the  host  machine  and  is  used  for  downloading 
the  executable  images  to  the  target  machine.  The  DDC-I  Debug 
Monitor  runs  on  the  target  machine  and  provides  communication 
interface  between  the  host  downloader  and  the  executing  target 
machine.  The  two  processes  communicate  via  etheraet. 

The  tests  were  compiled  and  linked  on  the  host  computer  system,  as 
appropriate.  The  executable  images  were  transferred  to  the  target 
computer  system  by  the  communications  link  described  ed>ove,  and 
run.  The  results  were  captured  on  the  host  computer  system. 

Testing  was  performed  using  command  scripts  provided  by  the 
customer  and  reviewed  by  the  validation  team.  See  Appendix  B  for 
a  complete  listing  of  the  processing  options  for  this 
implementation.  It  also  indicates  the  default  options.  The 
options  invoked  explicitly  for  validation  testing  during  this  test 
were: 

-list 

Test  output,  compiler  and  linker  listings,  and  job  logs  were 
captured  on  magnetic  tape  and  archived  at  the  AVF.  The  listings 
examined  on-site  by  the  validation  team  were  also  archived. 
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APPENDIX  A 


MACRO  PARAMETERS 


This  appendix  contains  the  macro  parameters  used  for  customizing 
the  ACVC.  The  meaning  and  purpose  of  these  parameters  are 
explained  in  CUG89].  The  parameter  values  are  presented  in  two 
tables.  The  first  table  lists  the  values  that  are  defined  in  terms 
of  the  maximum  input-line  length,  which  is  the  value  for 
$MAX_IN  LEM— also  listed  here.  These  values  are  expressed  here  as 
Ada  string  aggregates,  where  **7"  represents  the  maximum  input-line 
length. 

Macro  Parameter  Macro  Value 


$MAX_IN_LEN  126  —  Value  of  V 

$BIG_ID1  (1..V-1  «>  'A*,  V  ->  '1') 

$BIG_ID2  (1..V-1  «>  ‘A*,  V  *>  *2') 

$BIG_ID3  (1..V/2  «>  ‘A’)  &  *3'  &  (1..V-1-V/2  ->  'A*) 

$BIG_ID4  (1..V/2  =>  'A*)  &  '4'  &  (1..V-1-V/2  •>  'A') 

$BIG_INT_LIT  (1..V-3  «>  *0')  &  "298" 

$BIG_REAL_LIT  (1..V-5  «>  '0')  &  "690.0" 

$BIG_STRING1  &  (1..V/2  ->  'A')  & 

$BIG_STRING2  &  (1..V-1-V/2  »>  'A')  &  '1'  & 

$BIiANKS  (1..V-20  *>  •  •) 

$MAX_LEN_INT_BASED_LITERAL 

"2:"  &  (1..V-5  ->  '0')  &  "11:" 

$MAX_LEN_REAL_BASED_LITERAL 

"16:«  &  (1..V-7  ->  *0')  &  "F.E:" 

$MAX_STRING_LITERAL  &  (1..V-2  ->  'A')  &  •""• 
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The  following  table  contains  the  values  for  the  remaining 
macro  parameters. 

Macro  Parameter  Macro  Value 


ACC_SIZE 

ALIGNMENT 

COUNT_LAST 

DEFAULT_MEM_SIZE 

DEFAULT_STOR_UNIT 

DEFAULT_SYS_NAME 

DELTA_DOC 

ENTRy_ADDRESS 

ENTRy_ADDRESSl 

ENTRY_ADDRESS2 

FIELD_LAST 

FILE_TERMINATOR 

FIXED_NAME 

FLOAT_NAME 

FORM_STRING 

FORM  STRING2 


48 

2 

2_147_483_647 

16#1_0000_0000# 

16 

IAPX586_PM 

2«1.0«E-31 

(140,0) 

(141,0) 

(142,0) 

35 

ASCII. SUB 
NO_SUCH_FIXED_TYPE 
SHORT  SHORT  FLOAT 


GREATER_THAN_DURATION 
GREATER_THAN_DURATION_BASE  LAST 
GREATER_THAN_FLOAT_BASE_LAST 
GREATER_THAN_FLOAT_SAFE_LARGE 
GREATER  THAN_SH0RT_FL0AT  SAFE_LARGE 
HIGH_PRIORITY 

ILLEGAL__EXTERNAL_FILE_NAME1 
ILLEGAL_EXTERNAL_FILE_NAME2 

THIS-FILE-NAME-IS-TOO-LONG-FOR-MY-SYSTEM 


"CANNOT_RESTRICT_FILE_CAPACITY“ 
75_000.0 
131_073.0 
16il.0«E‘l'32 
16#5.FFFF_F0#E+31 
1.0E308 
31 

\NODIRECTORY\FILENAME 


INAPPROPRIATE_LINE_LENGTH 
INAPPROPRIATE_PAGE_LENGTH 
INCLUDE  PRAGMAl 


-1 

-1 


PRAGMA  INCLUDE  (''A28006D1.ADA") 


INCLUDE_PRAGMA2 

INTEGER_FIRST 

INTEGER_LAST 

INTEGER  LAST_PLDS_1 

INTERFACE_LANGUAGE 

LESS_THAN_DURATION 

LESS_THAN_DURATION_BASE_FIRST 

LINE_TERMINATOR 

LOW_PRIORITY 

MACHINE_CODE_STATEMENT 

MACHINE_CODE_TYPE 
MANTISSA  DOC 


PRAGMA  INCLUDE  (’'B28006E1. ADA") 

:  -2147483648 
:  2147483647 

:  2_147_483_648 
:  ASM86 
:  -75_000.0 
:  -131_073.0 
:  ASCII. CR 
:  0 

MACHINE_INSTRUCTION' (NONE,m_NOP) ; 
;  REGISTER_TYPE 
I  31 
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MAX_DIGITS 

MAX_INT 

HAX_INT_PLUS_1 

MIN_INT 

NAME 

NAME_LIST 

NAME_SPECIFICATI0N1 

DISK$AWC_2: [CROCKETTL. 
NAME  SPECIFICAT10N2 


:  15 

:  9223372036854775807 
:  9223372036854775808 
:  -9223372036854775808 
:  SHORT_SHORT  INTEGER 
:  IAPX586_PM  “* 

ACVCll . DEVELOPMENT] X2 120A 


DISK$AWC  2 
NAME__SPECIFICATION3 

DISK$AWC_2 
NEG_BASED_INT 
NEW_MEM_SIZE 
NEW_STOR_UNIT 
NEW_SYS__NAME 
PAGE_TERMINATOR 
RECORD_DEFINITION 
RECORD_NAME 
TASK_SIZE 
TASK_STORAGE_SI ZE 
TICK 

VARIABLE_ADDRESS 
VARI ABLE_ADDRESS 1 
VARI ABLE_ADDRESS  2 
YOUR  PRAGMA 


:_2 :  [CROCKETTL. ACVCll. DEVELOPMENT]X2120B 


[  CROCKETTL.  ACVCll .  DEVELOPMENT]  X3 119A 

16#FFFF_FFFF_FFFF_PFFF# 
16#1_0000_0000# 

16 

IAPX586_PM 
ASCII. FF 

RECORD  NULL; END  RECORD; 
NO_SUCH_MACHINE_CODE_TYPE 
32 

1024 

0.000_000_062_5 
(16#0#,16#44#) 
(16#4#,16#44#) 
(16«8#,16«44«) 

EXPORT  OBJECT 
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APPENDIX  B 


COMPILATION  SYSTEM  OPTIONS 


The  compiler  options  of  this  Ada  implementation,  as  described  in  this 
Appendix,  are  provided  by  the  customer.  Unless  specifically  noted 
otherwise,  references  in  this  appendix  are  to  compiler  documentation  and 
not  to  this  report. 
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5  THE  ADA  COMPILER 


The  Ada  Compiler  compiles  all  program  uniu  within  the  specified  source  file  and  inserts  the 
generated  objem  imo  the  currem  progran  library.  Compiler  options  are  provided  to  allow  the 
user  control  of  opiimizatiorL  noMime  checks,  and  compiler  input  and  output  options  such  as  list 
flies,  configuration  files,  the  program  library  used,  etc. 

The  input  to  the  compiler  consists  of  the  source  fUe,  the  configuration  file  (which  controls  the 
format  of  the  list  file),  and  the  compiler  options.  Secdon  S.l  provides  a  list  of  all  compiler 
options,  and  Section  i2  describes  the  source  and  configtoaiion  files. 

If  any  diagnostic  messages  are  produced  during  the  compilation,  they  are  output  on  the  diagnostic 
file  and  on  the  currem  output  file.  The  diagnostic  file  nd  the  diagnostic  messages  are  described 
in  Sectian  S.3.2. 

Output  consists  of  an  objea  placed  in  the  program  library,  diagnostic  messages,  and  optional 
listings.  The  configuration  file  and  the  compiler  options  specify  the  format  and  contents  of  the 
list  information.  Oitput  is  described  in  Section  S.3. 

The  compiler  uses  a  program  library  during  the  compilation.  The  compiladon  unit  may  refer  to 
units  from  the  program  library,  and  an  internal  representation  of  the  compilation  unit  will  be 
included  in  the  program  library  as  a  result  of  a  successful  compilation.  The  program  library  is 
described  in  Chapter  3.  Section  S.4  briefly  describes  how  the  Ada  compiler  uses  the  library. 


5.1  Invoking  the  Ada  Compiler 

Invoke  the  Ada  compiler  with  the  following  command  to  the  SunOS  shell: 

S  ada  {<option>}  <sourcc>nic>naine> 
where  the  options  and  parameten  are: 
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OPTION 

DESCRIPTION  REFERENCE 

•(nolauiojnline 

Specifies  whether  local  subprograms  should  be 

5.1.1 

-■ - ■- 

•CMCK 

inline  expanded 

Connols  nm^cime  checks. 

5.1.2 

•conllguratioii^fBe 

Spedflei  the  configuratioo  file  used  by  the 

5.1.3 

•(noKkbtig 

conqiiler. 

Includes  symbolic  debugginf  infbnnation  in 

5.1.4 

•(no)ffacpoint_itMtndifif 

program  Library.  Does  not  include  symbolic 
infbnnadoa 

Generaies  fixed  point  rounding  code.  Avoids  fixed 

5.1.5 

•(nolfioat,  allowed 

point  rounding  code. 

Flags  generation  of  float  instructions  as 

5.1.6 

•(noWbrary 

error  if  selected. 

Specifies  program  library  used. 

5.1.7 

•|no]Ust 

Writes  a  source  listing  on  die  list  file. 

5.1.8 

•ino]opiliiii» 

Specifies  compiler  optimization. 

5.1.9 

•Inolprofcss 

Displays  compiler  progress. 

5.1.10 

•(no)xref 

Creates  a  cross  reference  listing. 

5.1.11 

•[no)save_ao«ircc 

Copies  source  to  program  library. 

5.1.12 

•(noltartM  .debut 

Includes  Intel  debug  informadoa  Does  not  include 

5.1.13 

•unit 

Intel  debug  infbrmatictt 

Assigns  a  specific  unit  manber  to  the  compilation 

5.1.14 

•recompile 

(must  be  free  and  in  a  sublibrary). 

Ifuerpret  the  file  name  as  a  compilation  unit  body 

that  must  be  recompiled  horn  library. 

5.1.15 

•spedfkatiQii 

With  •recompile  interpret  file  name  as  a 
compilatioo  unit  specification  rather  than  body. 

5.1.16 

Examples: 

S  ada  -Hat  taatpsog 

This  example  compiles  (he  source  file  tcstprofjida  and  genenies  a  list  file  with  die  name 
tcstprogJIa. 

$  ada  •lihzaxy  ay^Uteaxy  taat 

This  example  compiles  die  source  file  testada  into  die  library  aqr^Hhivy. 

Default  values  exist  for  most  options  as  indiemed  in  die  fbUowhif  secdoni.  Opcioo  names  may 
be  abbreviated  (characteis  omioed  fnm  (be  right)  as  tong  as  no  ambiguity  vis^ 
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<aoiuxe>lll»4iani> 

The  Ada  compiler  hai  one  mandaiofy  parameter  dial  should  specify  die  Ada  source  file. 

This  parameter  spedfies  die  mat  fUe  comaiiiing  die  source  text  to  be  compiled.  If  die  flk  type 
is  omitted  in  the  source  file  spedficaboB.  the  ^  type  "mU  '  is  assumed  by  defauh. 

The  allowed  fbimat  of  the  source  text  is  desotted  in  Section  52.1. 


Below  follows  a  description  of  each  of  the  available  optioos  to  the  invocaiion  of  the  Ada 
compiler. 


5.1.1  •{ae]aiMo_iBihic 

•auto  inUne  WiffI  |  glohal 
•noauio^inliac  (default) 

This  option  specifies  whether  subproframs  should  be  inline  expanded.  The  inline  expansion  only 
OCCUR  if  die  subprofram  has  less  than  4  obfea  declaratioBS  and  kas  than  6  statements,  and  if  the 
subprognm  folfDls  die  requirements  defined  for  pragma  INLINE  (see  Section  C.2.3).  LOCAL 
specific  that  only  inline  expansion  of  locally  defined  subpregtams  should  be  done,  while 
<«LOBaL  win  cause  inline  expansloo  of  all  subprograms,  induding  subprograms  fiom  other  uniis. 


5.1.2  <€110011 


•Chech  (  <hayword>  «  ON  |  OFF  {  .<kayword>  «  ON  |  OFF  )  ) 
•check  ALL«ON  (defouh) 


•check  spedfies  which  ntiMime  checks  should  be  peifonncd.  Setting  a  noHitBe  check  to  ON 
enables  the  check,  while  setting  it  to  OFT  disabtes  the  check.  AB  nmnime  checks  are  enabled  by 
default  The  following  expUett  checks  will  be  disabiedAnabled  by  using  the  name  as  <keywonl>; 


ACCESS 

ALL 

DISCRIMINANT 

ELABORATION 

INDEX 

LENGTH 

OVERFLOW 

RANGE 

STORAGE 


Check  for  access  values  being  non  NULL. 
AH  checks. 

Checks  for  discriminaied  Odds. 

Checks  for  subprograms  being  dabonmd. 
Index  check. 

Amy  check. 

ExpUdt  overflow  checks. 

Checks  for  values  being  in  range. 

Checks  for  sufBdem  saorage  avaBabie. 
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S.1  J  <oailiHrmioa_fllc 


•«oiiflgitratioBL.lBc  <fIle>^Mo 
•€o«flfttntioa_lllc  coafif  (deCHdi) 

Tltts  opQon  specifies  the  configuniioa  file  lo  be  used  by  ibe  compiler  in  the  cunent  compilation. 
The  confifundon  file  allows  the  taer  to  fomtat  compiler  lisditfs.  set  enor  limits,  etc.  If  the 
option  is  omitted  the  configmaDoa  file  conOf  located  in  the  same  diicoofy  as  the  Ada  compiler 
is  used  by  dcfaiilL  Section  52J2  comains  a  desctipiion  of  the  oonfifuiacion  file. 


S.1.4  •{neKiebiif 


•mtkbiag  (dtAuk) 

Generate  debi^  infonnaiion  for  the  compilation  and  store  the  information  in  the  profram  library. 
This  is  necessary  if  the  unit  is  to  be  defaugied  with  the  DDC*I  Ada  Symbolic  Cross  Debugfer. 
Note  that  the  profram  must  atao  be  linked  with  the  •dahttg  opikm.  if  the  ptogram  is  to  be 
debugged  with  the  OOC-I  Ada  Syeabolic  Cross  Debugger.  See  Sectioo  6J.1 1. 


S.1JI  •{nelflapoim^rotMdint 

•IbpeiM^roondtag  (default) 

•MflapoiM^roondiag 

Normally  all  mline  generated  code  for  fixed  poim  MULTIPLY  and  DIVIDE  is  rounded,  but  this 
may  be  avoided  with  nc Wxpolni^reun  ding.  Inline  code  a  gwerased  for  all  16  bit  fixed  poim 
types  nid  for  32  bit  fixed  poim  types,  when  the  targes  is  I03I6PM  or  lOMfiPM. 


S.1A  »{no)Beni_allowad 

•floaa.aOewed  (dsfnih) 
♦nellMi.allewud 


Flom  insDuction  genaradon  amy  be  flagged  as  ttrom.  if  HMOoni  is  selsctad.  This  is  for  aae  hi 
systems,  wham  no  floming  poim  procesaor  (nor  eautator)  is  available.  Nodee  dm  TEXT.IO  uses 
floats  in  connection  whh  PLOAT.iO  and  FDCEDJO. 
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5.1.7  •library 

•library  <fllc^spco 

•library  $ada_Jibrary  (default) 

This  option  specifies  the  current  sublibraiy  that  will  be  used  in  the  compilation  and  will  receive 
(he  objea  when  the  compilation  is  complete.  By  specifying  a  current  sublibrary,  the  current 
program  library  (current  suMibrary  and  ancestors  up  to  root)  is  also  implicitly  specified. 

If  this  option  is  omitted,  the  sublibrary  designated  by  the  environmental  variable  adaJibrary  is 
used  as  the  current  sublibrary.  Section  5.4  describes  how  the  Ada  compiler  uses  the  library. 


5.1.8  -(nollist 


•list 

•noiist  (default) 

•list  specifies  that  a  source  listing  will  be  produced.  The  source  listing  is  written  to  the  list  file, 
which  has  the  name  of  the  source  file  with  the  extension  Jis.  Section  3.3. 1.1  contains  a  description 
of  the  source  listing. 

If  •nolist  is  active,  no  source  listing  is  produced,  regardless  of  LIST  pragmas  in  the  program  or 
diagnostic  messages  produced. 


5.1.5  •optimlae 

•opUmlae  (  <l(cywQrd>  «  on  |  off  {  .<kcyword>  s  on  |  off }  ] 

•optiroixt  ailsoff 

This  option  specifies  which  optimizations  will  be  performed  during  code  generanort  The  possible 
keywords  are:  (casing  is  irrekvm) 


all 

All  possible  optimizations  are  invoked. 

check 

Eliminates  si^ierfluous  checks. 

css 

Performs  common  subexpression  dimination  iiKluding  common 
address  expressions. 

fctlproc 

Change  fonoion  calls  returning  objects  of  conarained  array  types 
or  objccs  of  record  types  to  proodute  calls. 

1  iw  inhhh 

Traisforma  named  aggregates  to  positional  aggregates  and  named 
parancser  aswciaions  to  positiooa!  associations. 

nach-bdfbt 

Performs  stack  biaght  ledactioos  (also  called  Aho  UUman 
reortkrinf). 

block 

OpiiaBize  block  aid  aS  francs. 

Setting  an  opdmizaiion  to  on  enables  the  opdmizaiion.  wMle  KSing  at  opthntzaiion  to  off  disables 
the  optimization.  All  optimizations  are  dlsabicd  by  deteilL  In  addiiion  to  the  optional 
optimizations,  the  compiler  always  performs  the  foUowing  opthnizaions:  constant  folding,  dead 
code  diminaion.  aid  sdeoion  of  optimal  jumps. 
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S.1.10  •(nolprofrcss 


*profr  us 

•aoproysss  (deteilt) 

Wben  this  opdon  is  given,  ite  cooqiikr  will  output  daa  sbout  wlach  pus  ibe  compiler  is 
cunendy  nmninf. 


S.1.11  •{no)xref 
•sref 

•noxrcf  (deteilt) 

A  cross-reference  Usting  can  be  icquesud  by  the  user  by  means  of  the  option  -mf.  If  the  -xref 
(^on  is  given  and  no  severe  or  fiial  enon  are  foimd  during  the  compiladon.  the  cross-refetence 
listing  is  written  to  the  list  fik.  The  eross-refeience  listing  is  described  in  Sectkm  ?. 


5.1.12  •(no]savc_aouroe 

•savc.soufTt  (default) 

•nosa^^source 

When  •«ve..joures  is  spedficd.  a  copy  of  the  compiled  source  code  is  placed  in  ihe  propam 
library.  If  -nosavt^source  is  used,  source  code  wiU  not  be  retained  in  the  program  libn^. 

Using  •noaavt.jourcc.  while  helping  to  keep  library  sixes  sauller.  dou  affea  the  operatioo  of 
the  recorapikr,  see  Chapter  7  for  mom  details.  Also,  it  wiO  not  be  possible  »  do  symbolic 
debugging  at  the  Ada  source  code  Irml  whh  the  DACS-IOxSd  Symbolic  Ada  Debugger,  if  the 
source  code  is  not  saved  in  the  Ubiaiy. 


5.1.13  -(neltargtt-dcbttg 

•tartm_debug 
•aourgtt.debof  (defeult) 

Spedlks  whether  symbolic  debug  tafonurion  on  amndard  OMF  is  included  in  the  objea  file. 
Cunendy  the  Ihiker  does  not  support  the  OMF  debug  infotmadoa 

This  opdon  may  be  used  when  debugging  wWi  amndard  mob  0-e..  PICE). 
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S.1  J4  Mmit 


•unU  «  <uBtt_iiuiBbef> 

Tbe  specified  unit  number  will  be  assiped  u  the  compilation  unit  if  it  is  fiee  and  it  is  a  legal 
unit  number  ter  the  library. 


5.1.15  -recompile 
•recompUe 

The  file  name  (source)  is  interpreted  as  a  oompilacioo  unit  name  whiefa  has  its  source  saved  ftom 
a  previous  compilation.  If  •sp^Acaiioo  is  not  specified,  it  is  ammed  to  be  body  which  must  be 
recompiled. 


5.1.16  -spcdficaikMi 


-qttdflcaUon 

Works  only  together  with  •recompfic.  see  Section  5.1.15. 


5  J  Compiler  Input 

Input  to  the  compiler  consistt  of  the  command  line  options,  a  source  text  file  nd.  optionally,  a 
configuration  file. 


5JJ  Source  Text 

The  user  submits  one  file  ooMairing  a  source  text  in  each  compilation.  Tbe  source  text  may 
consist  of  one  or  more  coi^pilatioo  units  (see  ARM  Section  10.1). 

The  format  of  the  source  text  must  be  in  ISO-RHIMAT  ASCn.  This  fonnat  requires  that  the 
source  text  is  a  sequence  of  ISO  characien  (ISO  sundard  646).  where  each  line  is  terminated  by 
either  one  of  the  f^wing  termination  sequences  (OR  means  carriage  return.  VT  means  vertical 
tabulation.  LF  means  litre  feed,  and  FF  means  fonn  feed): 

•  A  sequence  of  one  or  more  CRs.  where  the  sequence  is  ireidrer  hmirediate  ly  preceded  nor 
immediately  followed  by  any  of  the  charaoeta  VT.  LF.  or  FF. 

•  Any  of  the  characters  VT.  LF.  or  immediately  preceded  and  followed  by  a  sequence  of  zero 
or  more  QU. 

In  general.  ISO  control  characters  are  not  petmioed  in  the  source  text  with  the  following 
exceptions: 
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•  The  horizontal  tabulation  (HT)  character  may  be  used  as  a  separator  between  lexical  units. 

•  LF,  VT,  FF,  and  CR  may  be  used  to  terminate  lines,  as  described  above. 

The  maximum  number  of  characten  in  an  input  line  is  determined  by  the  contents  of 
configuration  file  (see  section  5.1.3).  The  control  charaaers  CR.  VT,  LF,  and  FF  are 
considered  a  part  of  the  line.  Lines  containing  more  than  the  maximum  number  of  charaaers 
truncated  arul  an  error  message  is  issued. 


5JL2  Configuration  FUc 

Certain  processing  characteristics  of  the  compiler,  such  as  fonnat  of  input  and  ou^t.  and  error 
limit  may  be  modified  by  the  user.  These  characteristics  are  passed  to  the  compiler  by  means 
of  a  configuration  file,  which  is  a  standard  SPARGSunOS  text  file.  The  contents  of  the 
configuration  file  must  be  an  Ada  positional  aggregate,  wrinen  on  one  line,  of  the  type 
CONFICURATION.RECORD,  which  is  described  below. 

The  configuration  file  (config)  is  not  accepted  by  the  compiler  in  the  following  cases: 

•  The  syntax  does  not  confonn  with  the  syntax  for  positional  Ada  aggregates. 

•  A  value  is  outside  the  ranges  specified. 

•  A  value  is  not  specified  as  a  literal. 

•  UNES.PER.PAGE  is  not  greater  than  TOP_MARGIN  +  BOTTOM.MARGIN. 

•  The  aggregate  occupies  mote  than  one  line. 

If  the  compiler  is  unable  to  accept  the  configuration  fik,  an  error  message  is  written  on  the 
current  output  file  and  the  compilation  is  terminated. 

This  is  the  record  whose  values  must  appear  in  aggregate  fonn  within  the  configuration  file.  The 
record  declaration  makes  use  of  some  other  types  (given  below)  for  the  sake  of  clarity. 
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type  CONFZGURATZON.RCCORO  is 
record  "" 

ZN  FORMAT:  ZMFORMATTZNG; 

OUT  FORMAT:  OUTFORMATTZNG; 

ERROR^LZMZT:  ZNTECSR; 
end  record; 

type  ZNPUT_FORMATS  is  (ASCZZ); 

type  ZMFORMATTZMG  is 
record 

ZNPUT  FORMAT:  ZNPUT  FORMATS; 

ZMPUT~LZNELEMGTH:  ZNTE6ER  range  '70.. 250; 
end  record; 

type  OUTFORMATTZNG  is 
record 

LZNES  PER  PAGE  :  ZNTEGER  range  30.. 100; 

T0P_MAR6ZN  :  ZNTEGER  range  4..  90; 

BOTTOM  MARGZN  :  ZNTEGER  range  0..  90; 

OUT_LzmzXNGTH  :  ZNTEGER  range  80..  132; 

SUPPRESS_ERRORNO  :  BOOLEAN; 

end  record; 

Tte  outformaoing  parameteis  have  the  following  meaning; 

1}  UNES.PER.PACE:  specifies  the  maxirauni  nimtber  of  lines  written  on  each  page 
(including  top  and  bottom  margin). 

2)  TOP_MARGIN:  specifies  the  number  of  lines  on  top  of  each  page  used  for  a  standard 
heading  and  blank  lines.  Hie  heading  is  [riaced  in  the  middle  lines  of  the  top  margin. 

3)  BOTTOM.MARGIN:  specifies  the  minimum  number  of  lines  left  blank  in  the  bottom  of 
the  page.  The  number  of  lines  available  for  the  listing  of  the  ptogtam  is  LINES 
PER_PAGE  •  TOP_MARGIN  -  BOTrOM_MARGIN. 

4)  OUT.UNELENGTH:  specifies  the  maximum  number  of  characters  written  on  each  line. 
Lines  longer  than  OUT.LINELENGTH  are  separated  into  two  lines. 

5)  SUPPR£SS_ERRORNO;  specifies  the  fonnat  of  error  messagm  (see  Section  S.3.5.1). 

The  name  of  a  user-sup|died  configuration  file  can  be  passed  to  the  cmnpiler  through  the 
connguration_file  option.  DOC-I  supplies  a  default  configuiaiion  file  (config)  with  the  following 
contem: 
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((ASCn.  126),  (4843.10aFALSE).  200) 


Top 

■arpln 


linaa 

P«r 

p«9« 


lot tea 
Mx«ln 


Out_Iine_Iengih 

Figure  5<1.  Page  Layout 


5  J  Compiler  Output 

The  compiler  may  produce  output  in  the  list  Ole.  the  diagnostic  Ole.  md  the  cunent  output  Ole. 
It  also  updates  the  program  library  if  the  compilaiitm  is  successful  The  present  section  describes 
the  text  output  in  the  three  Oles  mentioned  above.  The  updating  of  the  program  Ubiaiy  is 
described  in  Section  S.4. 

The  compiler  may  produce  the  following  text  output: 

1)  A  listing  of  the  source  text  with  embedded  diagnostic  messages  is  wrioen  on  the  list  fQe, 
if  the  option  'list  is  active. 

2)  A  compiUttion  summary  is  written  on  the  list  Ole.  if  *1181  is  active. 


3)  A  cross-reference  listing  is  written  on  the  list  Ole.  if  -xrcf  is  active  and  no  severe  or  fatal 
errors  have  been  detected  during  the  compilttion. 


4)  If  there  are  any  diagnostic  messages,  a  diagnostic  Ole  oontainii%  the  diagnostic  messages 

is  '^niien. 


5)  Diagnostic  messages  other  than  warnings  are  written  on  the  cunent  output  Ok. 


DACS-80x86  User's  Guide 
Ada  Compiler 


5  J.1  The  List  File 

The  name  of  the  list  file  is  identical  to  the  name  of  the  source  file  except  that  it  has  the  file  type 
"Jis".  The  file  is  located  in  the  cunem  (default)  directory.  If  any  such  file  exists  prior  to  the 
compilatkMu  the  newest  veision  of  the  file  is  deleted.  If  the  user  requests  any  listings  by 
specifying  the  options  -list  or  -xref,  a  new  list  file  is  created. 

The  list  file  may  include  one  or  more  of  the  following  parts:  a  source  listing,  a  cross-reference 
listing,  and  a  compilation  summary. 

The  parts  of  the  list  file  are  separated  by  page  ejects.  The  contents  of  each  part  are  described  in 
the  following  sections. 

The  format  of  the  output  on  the  list  file  is  controlled  by  the  configuration  file  (see  Secoon  522) 
and  may  therefore  be  controlled  by  the  user. 


5J.1.1  Source  Listing 

A  source  listing  is  an  unmodified  copy  of  the  source  text  The  listing  is  divided  into  pages  and 
each  line  is  supplied  with  a  line  number. 

The  number  of  lines  output  in  the  source  listing  is  governed  by  the  occurrence  of  LIST  pragmas 
and  the  number  of  objectionaUe  lines. 

•  Parts  of  the  listing  can  be  suppressed  by  the  use  of  the  LIST  pragma. 

•  A  lirte  containing  a  construct  that  caused  a  diagnostic  message  to  be  produced  is  printed  even 
if  it  occurs  at  a  point  where  listing  has  been  suppressed  by  a  LIST  pragma. 


5J.1.2  Compilation  Summary 

At  the  end  of  a  compilation,  the  compiler  produces  a  summary  that  is  output  on  the  list  file  if  the 
option  -list  is  active. 

The  summary  contains  information  about: 

1)  The  type  and  name  of  the  compilation  unit,  and  whether  it  has  been  compiled  successfully 
or  ru>t 

2)  The  number  of  diagnostic  messages  produced  for  each  class  of  severity  (see  Secoon 
5.3.2.1). 

3)  Which  options  were  active. 

4)  The  full  name  of  the  source  file. 

5)  The  full  name  of  the  currem  sublibrary. 

6)  The  number  of  source  text  lines. 
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7)  The  size  of  the  code  produced  (spectlied  in  bytes). 

8)  Elapsed  real  time  and  elapsed  CPU  dme. 

9)  A  "COmpiladon  lenninaied*  message  if  the  compilation  unit  was  the  last  in  the  compilation 
or  "Conqulation  of  next  unit  initialed*'  otherwise. 


S  J.U  Cross-Reference  Listing 

A  cross-reference  listing  is  an  alphabetically  sotted  list  of  the  ideniifien,  operators,  and  character 
literals  of  a  compilation  uniL  The  list  has  an  entry  for  each  entity  declared  and/br  used  in  the 
unit,  with  a  few  exceptions  stated  below.  Overloading  is  evkknoed  by  the  occurrence  of  multiple 
entries  for  the  same  ideruifkr. 

For  instantiations  of  genetic  units,  the  visible  declaradortt  of  the  generic  unit  are  included  in  the 
cross-reference  listing  as  delated  immediately  after  the  instantiatioa  The  visible  declarations  are 
the  subprogram  parameters  for  a  generic  subprogram  and  the  declarations  of  the  visible  part  of  the 
package  declaration  for  a  generic  package. 

For  type  declarations,  all  implicitly  declared  operations  are  included  in  the  cross-reference  listing. 

Cross-reference  infomtation  will  be  produced  for  every  consdniem  character  literal  for  string 
literals. 

The  following  are  not  included  in  the  cross  reference  lining: 

•  Pragma  identiflers  and  pragma  argumem  ideniifiets. 

•  Numeric  literals. 

•  Record  cornponem  identifiers  and  discriminam  identifiers.  For  a  selected  name  whose  selector 
demtes  a  record  cornponem  or  a  discriminant,  only  the  prefix  generates  cross-reference 
informatioa 

•  A  parem  unit  name  (following  the  keyword  SEPARATE). 


Each  entry  in  the  cross-reference  listing  contains: 


•  The  identifier  with,  at  most.  IS  characters.  If  the  ideniilier  exceeds  IS  characters,  a  bar  fP) 
is  written  in  the  16ih  position  and  the  test  of  the  diaracters  are  not  primed. 

•  The  place  of  the  definition,  le..  a  line  number  if  the  entity  is  declared  in  the  currem 
compilation  unit,  otherwise  the  name  of  the  compilmion  unit  in  which  the  entity  is  dedared 
and  the  line  number  of  the  declaration. 

•  The  numbers  of  the  lines  in  which  the  entity  is  used.  An  asterisk  C*”)  affer  a  line  number 
indicates  an  assignmem  to  a  variable,  initialization  of  a  constant,  assignments  to  fioictions,  or 
user-defined  operaton  by  means  of  RETURN  statements.  Please  refer  to  Appendix  B J  for 
examples. 
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5JJ  The  Diagnostic  Fite 

*rhe  name  of  tbe  diagnostic  file  is  ktendcal  to  the  name  of  the  source  file  except  that  it  has  the 
file  type  ".err”.  It  is  located  in  the  cunem  (default)  directory.  If  any  such  file  exists  prior  to  the 
comi^laiion.  the  newest  version  of  the  file  is  deleted.  If  any  diagnostic  messages  are  produced 
during  the  compilation  a  new  di^piostic  fiie  is  created. 

The  diagnostic  file  is  a  text  file  containing  a  list  of  diagnostic  messages,  each  foQowed  by  a  line 
showing  the  number  of  the  lirm  in  the  source  text  causing  the  message,  and  a  blank  line.  'There 
is  no  separaiian  into  pages  md  no  headings.  The  file  may  be  used  by  an  interactive  editor  to 
show  the  diagnostic  messages  together  with  the  erroneous  source  text 


5J.2.1  Diagnostic  Messages 

Thi  Ada  compiler  issues  diagnostic  messages  on  the  diagnostic  file.  Diagnostics  other  than 
warnings  also  appear  on  the  currem  output  file.  If  a  source  text  listing  is  required,  the  diagnostics 
are  also  found  embedded  in  the  list  file  (see  Section  5.3.1). 

In  a  source  listing,  a  diagix>stic  message  is  (daced  immediately  after  the  source  line  causing  the 
message.  Messages  not  related  to  any  particular  line  are  plac^  at  the  top  of  the  listing.  Every 
diagnostic  message  in  the  diagnostic  file  is  followed  by  a  line  stating  the  line  number  of  the 
objecdonal  line.  The  lines  ate  ordered  by  increasing  source  line  numbers.  Line  number  0  is 
assigned  to  messages  not  related  to  any  particular  line.  On  the  cunem  output  file  the  messages 
appear  in  the  order  in  which  they  are  generated  by  the  compiler. 

The  diagnostic  messages  are  classified  according  to  their  severity  and  the  compiler  action  taken: 


Warning:  Reports  a  questionable  construa  or  an  error  that  does  not  influence  the  meaning  of  the 
program.  Warnings  do  not  hinder  the  generation  of  objea  code. 

Exam{rfe:  A  warning  will  be  issued  for  constructs  for  which  the  compiler  detects  will 
raise  CONSTRAlNT_ERROR  «  run  time. 


Error  Reports  an  illegal  construct  in  the  source  program.  Compilation  continues,  but  no  objea 
code  will  be  generated. 

Examples:  most  syntax  errors;  most  static  semantic  errors. 


Severe  Reports  an  error  which  causes  the  compilation  to  be  terminated  immediately, 
error.  No  object  code  is  generated. 

Example:  A  severe  error  message  wifi  be  issued  if  a  library  unit  mentioned  by  a 
WITH  clause  is  not  presem  in  the  cunem  program  library. 
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Fatal  Reports  an  error  in  the  compiler  system  itself.  Compilation  is  terminated  immediately 

error  and  no  object  code  is  produced.  The  user  may  be  able  to  circumvem  a  fatal  error  by 

correcting  the  program  or  by  replacing  program  constructs  with  alternatives.  Please 
inform  DDC-I  about  the  occurrence  of  fatal  errors. 


The  detection  of  mote  errors  than  allowed  by  the  number  specified  by  the  ERROR.LIMrr 
parameter  of  the  configuration  file  (see  section  522)  is  consitteted  a  severe  error. 


5 J Format  and  Content  of  Dia^iostic  Messafes 

For  certain  syntacticaily  incotrea  constructs,  the  diagnostic  message  consists  of  a  pointer  line  and 
a  text  line.  In  other  cases  a  diagnostic  message  consists  of  a  text  line  only. 

The  pointer  line  contains  a  pointer  (a  cant  symbol  to  the  offending  symbol  or  to  an  illegal 
character. 

The  text  line  contains  the  following  information: 

•  the  diagnostic  message  identification  "***” 

•  the  message  code  XY*Z  where 

X  is  the  message  number 

Y  is  the  severity  code,  a  letter  showing  the  severity  of  the  error 

W:  warning 
E:  error 
S:  severe  error 
F:  fatal  error 

Z  is  an  integer  which,  together  with  the  message  number  X.  uniquely  ktentifies  the  compiler 
location  that  getKtated  the  diagnostic  message:  Z  is  of  importance  mainly  to  the  compiler 
maintenance  team  -  it  does  not  contain  information  of  interest  to  the  compiler  user. 

The  message  code  (with  the  exception  of  the  severity  code)  will  be  suppressed  if  the 
parameter  SUPPRESS.ERROR.NO  in  the  configuration  file  has  the  value  TRUE  (see 
section  522). 

•  the  message  text;  the  text  may  include  one  cotuext  dependem  field  that  contains  the  name  of 
the  offending  symbol:  if  the  name  of  the  offentUng  symbol  is  longer  than  16  characters  only 
the  first  16  characters  ate  shown. 

Examples  of  diagnostic  messages: 

***  18M-3:  Warning:  Exception  CONSTRAXHTJEnROR  will  be  caisad  hare 

•**  320E-2:  Naina  OBJ  does  not  danota  a  type 

***  535E-0:  Expression  in  return  statamant  missing 
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***  ISOSS'O:  Specification  foe  this  package  body  not  present  in  the  library 


5.4  The  Program  Library 

This  section  briefly  describes  how  the  Ada  compiler  changes  the  program  libraiy.  For  a  more 
general  description  of  the  program  library,  the  user  is  lefetred  to  Chapter  3. 

The  compiler  is  allowed  to  read  ftom  ail  subiibiaries  constituting  the  cuncm  program  Ubrary.  but 
only  tbe  canem  subUbrary  may  be  changed. 


5.4.1  Correct  Compilations 

In  tbe  following  examines  it  is  assumed  that  the  compilation  units  are  correctly  compiled.  i.e..  that 
no  erron  are  detected  by  tbe  compiler. 


Compilation  of  a  library  unit  which  is  a  declaration 

If  a  declaration  unit  of  the  same  name  exists  in  the  current  sublibraiy.  it  is  deleted  together  with 
its  body  unit  and  possible  subunits.  A  new  declaration  unit  is  inserted  in  tbe  sul^brary.  together 
with  an  empty  body  unit 

Compilation  of  a  library  unit  which  is  a  subprogram  body 

A  subprogram  body  in  a  compilation  unit  is  treated  as  a  secondary  unit  if  tbe  cunettt  sublibraiy 
contains  a  subprogram  declaration  or  a  generic  subprogram  declaratioo  of  the  same  name  and  this 
declaration  unit  is  not  invalid.  In  all  other  cases  it  will  be  treated  as  a  library  unit.  i.e.: 

•  when  there  is  i»  libraiy  unit  of  that  name 

•  when  there  is  an  invalid  declaration  unit  of  that  nme 

■  when  there  is  a  package  declaration,  generic  package  dedaraiion.  an  instantiated  package,  cr 
subprogram  of  that  name 


Conqiilation  of  a  library  unit  which  is  an  instantiatioa 

A  possible  existing  declaration  unit  of  that  name  in  the  currem  sublibraiy  is  deleted  together  with 
its  body  unit  and  possible  subunits.  A  new  declaraioo  unit  is  inserted. 


Compila  ion  of  a  secondary  unit  which  is  a  library  unit  body 

The  existing  body  is  deleted  &om  the  subiibrary  together  with  its  possibk  subunits.  A  new  body 
unit  is  inserted. 
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Compilatioa  of  a  secondary  unit  which  is  a  subunit 

If  the  subunit  exists  in  the  sublibrary  it  is  deleted  together  with  its  possible  subunits.  A  new 
subunit  is  insetted. 


5.42  Incorrect  Compilations 

If  the  compiler  detects  sn  error  in  a  compilation  unit,  the  program  libniy  will  remain  unchanged. 

Note  that  if  a  file  consists  of  several  compilation  units  and  an  enor  is  detected  in  any  of  these 
compilation  units,  the  pregram  libraty  wUl  not  be  updmed  for  any  of  the  compilation  units. 

5J  Instantiatioo  of  Generic  Units 

This  section  describes  the  niles  after  which  generic  instantiation  is  performed. 


5  J.l  Order  of  Compilation 

When  instaruiating  a  generic  unit,  it  is  required  that  the  entire  unit,  including  body  arxl  possible 
subunits,  be  compiled  before  the  first  instantiatioa  This  is  in  accordance  with  the  ARM  Chapter 
10.3  (1). 


5.5.2  Generic  Formal  Private  Types 

The  present  section  describes  the  treatment  of  a  generfo  unit  with  a  generic  formal  private  type, 
where  there  is  some  construa  in  the  generic  unit  that  requires  that  the  corresponding  actual  t^^ 
must  be  constrained  if  it  is  an  array  type  or  a  type  with  discriminants,  and  there  exists 
instantiations  with  such  an  unconstrained  type  (see  ARM,  Section  12.32(4)).  This  is  considered 
an  illegal  combinatioa  In  some  cases  the  error  is  detected  when  the  instantiation  is  compiled,  in 
other  cases  when  a  constraint-requiring  construa  of  the  generic  unit  is  compiled: 

1)  If  the  instantiation  appears  in  a  later  compilation  unit  than  the  first  constraim-requiring 
construa  of  the  generic  unit,  the  error  is  associated  with  the  instaruiation  which  is  rejected 
by  the  compiler. 

2)  If  the  instaruiation  appears  in  the  same  compilation  unit  as  the  first  constraint-requiring 
construcQon  of  the  generic  unit,  there  ate  two  possibilities: 

a)  If  there  is  a  constraim-requiring  construction  of  the  generic  unit  after  the  instantiation, 
an  error  message  appears  with  the  instantiatioa 

b)  If  the  instantiation  appears  after  all  consul  requiting  constructs  of  the  generic  unit 
in  that  compilation  unit,  an  error  message  appears  with  the  constrrim-tequiring 
construct,  but  will  refer  to  the  iOegal  instantiatioa 
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3)  The  instantiation  appears  in  an  earlier  compilation  unit  than  the  hist  constraint-iequiring 
construction  of  the  generic  unit,  which  in  that  case  will  appear  in  the  generic  body  or  a 
subuniL  If  the  instantiation  has  been  accepted,  dte  instantiation  will  correspond  to  the 
generic  declaration  only,  and  not  include  the  body.  Nevenheless.  if  the  geiKric  unit  and 
the  instamiation  are  located  in  the  same  subiibrary,  then  the  compiler  will  consider  it  an 
error.  An  error  mess^  will  be  issued  with  the  constrairu-iequiring  construct  and  will  refer 
to  the  illegal  instantiation.  The  unit  containing  the  instanbation  is  not  changed,  however, 
and  will  not  be  marked  as  invalid. 


5.6  Uninitialized  Variables 

Use  of  uninitialized  variables  is  not  flagged  by  the  compiler.  The  effect  of  a  program  that  refers 
to  the  value  of  an  uninitialized  variable  is  undefined.  A  cross-reference  listing  may  help  to  And 
uninitialized  variables. 


5.7  Program  Structure  and  Compilation  Issues 

The  following  limitations  apply  to  the  OACS-80x86  Ada  Compiler  Systems  for  the  Real  Address 

Mode  and  286  protected  mode  only: 

•  The  Ada  compiler  supports  a  "modified  large"  memory  model  for  dau  references.  The 
"modified  large"  memory  model  associates  one  data  segmem  for  each  hierarchical  sublibrary  in 
the  Ada  program  library.  All  package  dau  declared  within  a  subiibrary  is  efficiently  referenced 
from  Ada  code  compiled  into  the  same  sublibrary.  A  sli^  increase  in  code  size  results  from 
referencing  package  dau  compiled  iruo  a  different  hierarchical  level.  Intel's  medium  memory 
model  can  thus  be  obtained  by  utilizing  only  one  tevel  of  Ada  program  library,  the  root 
sublibrary. 

•  The  Ada  compiler  supporu  a  large  memory  model  for  executable  code.  Although  the  size  of 
a  single  compilation  unit  is  restricted  to  32K  words,  the  total  size  of  the  code  portion  of  a 
program  is  not  restricted. 

•  The  space  available  for  the  static  dau  of  a  compilation  unit  is  64K  •  20  bytes. 

•  The  space  available  for  the  code  generated  for  a  coronation  unit  is  limited  to  32K  words. 

•  Any  single  objea  cannot  exceed  64K  •  20  bytes. 

The  following  iimiutions  apply  to  all  DACS-80x86  products: 

•  Each  source  file  can  contain,  at  roost,  32,767  lines  of  code. 

•  The  name  of  compilation  units  and  identiflers  may  not  exceed  the  number  of  characters  given 
in  the  INPUT.LINELENCTH  parameter  of  the  c^guration  file. 

•  An  integer  literal  may  not  exceed  the  range  of  LONG.INTEGER.  a  real  literal  may  not  exceed 
the  range  of  LONG_FLOAT. 
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•  The  number  of  foraial  perameten  petmioed  in  a  procedure  is  limited  to  127  per  parameter 
speciflcatloa  There  is  no  limit  on  the  number  of  procedure  specifications.  FOr  example,  the 
dedaruion: 

pcocodure  OVCK  LIMIT  (XNTCGEROl. 

XNTCGER02, 

•  •  •  *  « 

XIITCSE1U66:  in  XHTCGCR)  ; 

exceeds  the  limit,  but  the  procedure  can  be  accomplished  with  the  (bUowit^: 

procedure  UMOUt  LXMXT  (XHTtGCltOl  :  in  XMTBGER; 

XNTS6CI102  :  in  XMTCtXR; 

XMTCtOltiaa  :  in  IMTCGER)  ; 

The  above  limitations  are  diagnosed  by  the  oompikr.  In  practice  these  limitaiions  are  seldom 
restrictive  and  may  easily  be  circumvented  by  using  subunits,  separate  compilation,  or  creating  new 
subtibraries. 


5  J  CoinpUcr  Code  Optindsations 

DOC-I's  Ada  compiler  for  the  iAPX  80xS6  miooprocessw  Cunily  generares  compact,  efficient 
code.  This  efficiency  is  achieved,  in  pan.  by  the  compiler's  global  optimizer.  Optunizanons 
performed  indude: 

•  Common  subexpression  dimination 

•  Elimination  of  redundant  constraim  checks 

•  Elimination  of  redundant  elaboration  r*‘f**T 

•  Constant  folding 

•  Dead  code  elimination 

•  Optimal  regisier  allocation 

•  Selection  of  optimal  jumps 

•  Optional  nm-time  ch^  suppression 
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The  linker  options  of  this  Ada  implementation,  as  described  in  this 
Appendix,  are  provided  by  the  customer.  Unless  specifically  noted 
otherwise,  references  in  this  appendix  are  to  linker  dociunentation  and 
not  to  this  report. 
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6  THE  ADA  LINKER 


The  DACS  linker  must  be  executed  to  create  an  execuuble  program  in  the  target  environment 
Linkii^  is  a  two  stage  process  that  includes  an  Ada  link  using  the  compilation  units  in  the  Ada 
program  library,  and  a  target  link  to  integrate  the  application  code,  run-time  code,  and  any 
additional  configuration  code  developed  by  the  user.  The  linker  perfoims  these  two  suges  with  a 
single  command,  providing  options  for  controlling  both  the  Ada  and  target  link  processes. 

This  chapter  describes  the  link  process,  except  for  those  options  that  configure  the  Run-Time 
System,  which  is  described  in  detail  in  Chapter  7. 


6.1  Invoking  the  Linker 

Enter  the  following  command  at  the  shell  to  invoke  the  linker 
S  ada  Jink  {<option>}  <unit-natne> 
where  the  options  and  parameters  are: 

Ada  Linker  Options 


OPTION  DESCRIPTION  REFERENCE 


•[noldebug  Links  an  application  for  use  with  the  6.5.11 

OACS-80x86  Symbolic  Cross  Debugger. 

-cnablc_task_tracc  Enables  trace  when  a  task  terminates  in  6.5.28 

unhandled  exception. 

-cxception^space  Defines  area  for  exception  handling  in  task  stack.  6.529 

-(nolntrart  Extracts  Ada  Objea  modules  6.5.14 

>intcmipt_entry_^table  Range  of  interrupt  entries.  6.5.27 

-library  ”  *  The  library  used  in  the  link.  6.5.7 

-[nollog  Specifies  creation  of  a  log  file.  6.5.9 

-lt_scgment_size  Library  task  default  segment  size.  6.5  J3 

'lt~stack_size  Library  task  default  stack  size.  6.5J2 

-mp_segnicnt_size  Main  program  segmeru  size.  6J.25 

*mp~stack_sizc  Main  program  stack  size.  6JJ4 

-(nolnpx  ~  Use  of  the  80x87  numenc  coprocessor.  6J.16 

-options  Specifies  target  link  options.  6.5.6 

-priority  Default  task  priority.  6.5.18 

-reservc_stack  Size  of  reserve  stack.  6JJ1 

-rms  '  Select  Rate  Monotonic  Scheduling  Run-Tune  6J.13 

Kernel  (optional). 

Using  non-DDC-I  units  in  the  root  library. 


-(no]root_cxtract 


6J.10 


DACS-SOxM  User’s  Guide 
The  Ada  Linker 


•(nolrts 

Includes  or  exdudes  the  nm-time  system. 

6.5.12 

•searchlib 

Target  libraries  or  objea  modules  to  include 

6.5.4 

in  targa  link. 

•setecUveJink 

Removes  uncalled  code  firom  final  program. 

6.5.8 

•sign_on 

Produce  sign  on  and  sign  off  messages. 

6.5.30 

•stopJieforeJink 

Perfoms  Ada  link  only. 

6.5J 

•tasks 

Maximum  number  of  tasks  or  non-tasking 

6.5.17 

application. 

•task^storage.siac 

Tasks  default  storage  size. 

6J.26 

•tciii^c 

Specifies  templaie  file. 

6J.15 

•tinier 

Timer  resolution. 

6.5  JO 

•time_slice 

Task  dme  siidng. 

6.5.19 

All  options  may  be  abbreviated  (characters  omitted  from  the  right)  as  long  as  no  ambiguity  arises. 
Casing  is  signifkam  for  options  but  not  for  options  keywords. 

Note:  Several  simultaneous  links  of  the  same  program  should  not  be  performed  in  the  same 
directory. 


6.1.1  Diagnostic  Messages 

Diagnostic  messages  from  the  Ada  Linker  are  output  on  the  current  output  file  and  on  the  optional 
log  file.  The  messages  are  output  in  the  order  they  are  generated  by  the  linker. 

The  linker  may  issue  two  kinds  of  diagnostic  messages:  warnings  and  severe  errors. 

A  warning  reports  something  which  does  not  prevem  a  successful  linking,  but  which  might  be  an 
error.  A  warning  is  issued  if  there  is  something  wrong  with  the  body  unit  of  a  program  unit 
which  formally  does  not  need  a  body  unit.  e.g.  if  the  bt^y  unit  is  invalid  or  if  there  is  no  objea 
code  container  for  the  body  unit  Warnings  are  only  ou^t  on  the  log  flle.  not  on  the  currem 
output  nie.  The  linking  summary  on  the  log  file  will  contain  the  total  number  of  warnings  issued, 
even  if  the  issued  warnings  have  not  been  output. 

A  severe  error  message  reports  an  error  which  prevents  a  successful  linking.  Any  inconsistency 
delected  by  the  linker  wiU.  for  instaiKe.  cause  a  severe  error  message.  e.g.  if  some  required  unit 
does  not  exist  in  the  library  or  if  some  time  stamps  do  not  agree.  If  the  linker  is  used  for 
consequence  examination,  all  inconsistencies  introduced  by  the  hypothetical  recompilations  are 
reported  as  errors. 

A  imit  not  marked  as  invalid  in  the  program  library  may  be  reponed  as  being  invalid  by  the 
linker  if  there  is  something  wrong  with  the  unit  itself  or  with  some  of  the  units  it  depends  oa 


6J  The  Linking  Process 

The  linking  process  can  be  viewed  as  two  consecutive  processes.  Both  are  automatically  carried 
out  when  issuing  the  link  command  ada  Jink. 
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The  fim  process  consdnites  the  Ada  link  process  and  the  second  constitutes  the  target  link 
process. 

The  Ada  link  process 

•  retrieves  the  required  Ada  objea  modules  from  the  program  library, 

•  deteimines  an  elaboration  order  for  all  Ada  units, 

•  creates  a  module  containing  the  User  Configurable  Dau  (UCD)  from  the  specified  configuration 
options  to  the  linker  and 

•  creates  a  shell  script  that  carries  out  the  target  link  process  0-e..  dlnkbldx86).  The  locaie/build 
phase  is  an  iiuegral  pan  of  the  target  link. 


If  the  option  •stop-bcforeJink  is  NOT  specified  (default),  the  above  script  is  executed 
automatically.  (}therwise  the  linking  process  is  halted  at  this  point 

When  •stop-bcfore-link  is  specified,  all  temporary  files  are  retrieved  for  inspection  or 
modification.  The  target  linker  is  invoked  by  executing  the  shell  script 


6.2.1  Temporary  Files 

The  following  temporary  files  are  in  use  during  the  link  phase: 

<mainj)rogiam>.link.com  The  shell  script  which  invokes  the  target  linker. 

<mainj}rogram>_elabcode.o  The  objea  code  for  the  calling  sequence  of  the  elaboration 

code. 

<main_program>_ucd.o  The  objea  code  generated  from  the  RTS  configuration 

options  (see  Section  7.2). 

<main_progiam>_uxxxxx.o  The  Ada  objea  modules  which  have  been  extracted  fiom  the 

program  library,  xxxxx  is  the  unit  number  of  the  Ada  unit 
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The  following  components  make  up  the  nin-time  system: 

1)  User  configurable  portion  of  the  RTS 

a)  User  configurable  dau  (UCD)  and 

b)  User  configurable  code  (UCQ 

2)  Peraianem  pan  of  the  RTS 

a)  Non-tasking  RTS  (rllJib)  or 

b)  Tadcing  RTS  (rlliib) 

c)  RMS  Tasking  RTS  (rl3Jib) 

The  User  Configurable  Code  defined  by  the  environmental  vaiid^  ada^uocjib  is  included  in  the 
link.  If  no  tasking  has  been  specified,  then  the  RTS  non-tasking  libiaiy''(rli7lib)  will  be  included. 
If  tasking  has  been  specified,  then  suppon  for  tasking  wOl  be  included  (rl2Jib  or.  when  -rms. 
rl3.1ib). 
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The  output  of  the  linker  is  an  absoluie  execut^e  objea  file  with  the  extension  ’’.dat”  and 
a  map  file  with  the  extension  ".mpT. 


Environmental  Variables 

When  a  link  is  executed,  a  number  of  files  are  lefened  to  and  most  are  accessed  through 
environmental  vaiiables.  The  locate/build  phase  uses  the  comrol  file  SadA_ucc_dir/conrig.bkl_ddci, 
the  remaining  variaUes  are: 


VARIABLE 

PURPOSE 

ada_system_library 

Identifies  the  root  library  where  the  system  compOatitm  units  reside. 

adajibrary 

Identifies  the  default  library  used  by  all  DACS-80x86  tools.  It  is  the 
lowest  level  sublibrary  in  the  program  Ubrary  hierarchy. 

ada_rootjib 

Identifies  the  OMF  library  where  the  system  library  units  have  been 
extracted  from  the  system  library.  By  having  a  separaue  Library  for  the 
root  compilation  units,  the  link  process  is  much  faster  than  otherwise 
having  to  extraa  each  unit  from  the  system  library  for  each  link. 

ada_rll_lib 

Identifies  the  OMF  library  for  the  Pennanem  Part  of  the  non-tasking 
version  of  the  Run-Time  System. 

ada_rI2Jib 

Identifies  the  OMF  library  for  tiie  Permanent  Pan  of  the  tasking  veision 
of  the  Run-Tune  System. 

ada_rl3Jib 

Identifies  the  OMF  library  for  die  Permanem  Pan  of  the  optional  Rate 
Monotonic  scheduling  Run-Tune  System. 

ada.uccjib 

Identifies  the  OMF  library  for  the  User  COnfiguraUe  Code  portion  of 
the  Run-Time  System. 

ada-template 

Identifies  the  template  file  for  the  Linker. 

ada_ucc_dir 

Identifies  the  directory  of  the  cunem  UCC. 

With  each  of  these  environmental  variables,  the  name  will  differ  depending  on  bow  the  system 
was  installed  (ada86,  adaI86  etc).  Throughout  this  document  ada  is  assumed.  For  example,  the 
environmental  variables  for  the  root  libiaiy  for  the  80186  veision  of  the  compiler  would  be 
adal86_root_lib,  and  the  RTS  UCC  libraiy  environmental  variaUes  fer  the  8086  venrion  would 
be  ada86_ucc_lib. 
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6J  Run>Tiine  System  Overview 

The  Run-Tune  System  for  DACS-80x86  is  defined  as  all  code  and  data,  other  than  the  code  and 
data  produced  by  the  code  generator,  required  to  make  an  embedded  system  app?icaiioo  operate 
properly  on  a  specific  hardware  system. 

In  general,  there  are  two  major  componems  that  make  up  the  Run-Time  System. 

1)  Code  and  dau  assumed  to  exist  by  the  code  generator.  This  is  hardware  independem  and 
known  as  the  RTS  Pennanem  Pan. 

2)  Code  and  dau  tailoring  the  application  with  tespea  to  the  characteristics  of  the  hardware 
and  other  requirements  of  the  embedded  systems  developer.  Ilus  code  is  called  the  RTS 
User  Configurable  Part. 

Both  of  the  above  components  consist  of  modular  OMF  libraries.  The  modules  are  only  included 
in  the  user  program  if  they  are  needed.  i.e..  if  a  call  or  refereiKe  is  made  to  the  module.  This 
ensures  a  compaa  RTS  (typical  applications  are  4  KB  to  10  KB). 

The  RTS  Permanent  Pan  does  not  make  any  assumptions  about  the  hardware  other  than  an  80x86 
and  some  amoum  of  memmy  available. 

There  are  several  versions  of  the  RTS  User  Configurable  Pan  available  for  differera  development 
targets.  Also,  the  source  code  is  provided  to  allow  the  modification  of  the  User  Configunble 
Code  (UCC)  to  operate  on  other  targets.  Refer  to  the  RTS  Configuration  Guide  for  complete 
information  on  modifying  the  UCC. 

DDC-I  has  carefully  analyzed  and  selected  the  pans  of  the  Run-Time  System  that  must  be 
configurable  for  hardware  independence,  freeing  the  user  hom  major  rewrites  whenever  the 
Run-Time  System  is  retargeted  while,  still  allowing  for  almost  unlimited  adapubility. 

Four  important  features  of  the  run-time  system  are: 

•  It  is  small 

•  It  is  completely  ROMable 

•  It  is  configurable 

•  It  is  eRicient 


Conceptually,  an  Ada  run-time  system  can  be  viewed  as  consisting  of  the  following  components: 

•  Executive.  i.e..  the  stan-up  mechanism 

•  Storage  Management 

•  Tasking  Management 

•  Input/Ouqjut 

•  Exception  Handling 
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•  Run-Tune  Ubraiy  Routines 

•  Package  CALENDAR  suppon  mutines 


The  nin-time  system  (RTS)  can  be  configured  by  the  user  through  Ada  Linker  command  opdtm. 
The  Ada  Linker  will  generate  appropriate  dau  structures  to  represent  the  configured  characteristics 
(UCD). 

Two  versions  of  the  RTS  are  supi^ed,  one  including  tasking  and  one  exduding  tasking.  The 
linker  selects  the  RTS  verrion  including  tasking  only  if  die  option  -tasks  is  presem  or  -tasks  n 
is  presem  and  n  >  0.  Otherwise,  the  linker  selects  the  RTS  version  excluding  tasking. 


6.4  Linker  Elaboration  Order 

The  elaboration  order  is  primarily  given  by  the  unit  dependencies,  but  this  leaves  some  freedom 
here  and  there  to  arbitrarily  choose  between  two  or  more  alternatives.  This  arbitrary  is  in  the 
DACS-80x86  linker  controlled  by  the  spelling  of  the  involved  library  units,  in  order  for  "free” 
units  to  become  alphabetically  sorted. 

Recompiling  from  scratch,  an  entire  system  may  thus  affect  the  allocation  of  unit  numbers,  but  the 
elaboration  order  remains  the  same. 

It  is  also  attempted  to  elaborate  "body  after  body",  so  that  a  body  having  a  with  to  a  spedfication, 
will  be  attempted  elaborated  cfter  the  body  of  this  specification. 

Also  elaboration  of  units  from  differem  library  levels  is  attempted  to  complete  elaboration  of  a 
father-level  prior  to  the  son-leveL 

This  strategy  should  in  many  cases  reduce  the  need  for  resetting  pragma  ELABORATE. 


6J  Ada  Linker  Options 

This  section  describes  in  detail  the  Ada  linker  option  and  parameters. 


6J.1  The  Parameter  <unit-naine> 

<unit-naine> 

The  <unii_name>  must  be  a  library  unit  in  the  currem  program  library,  but  not  necessarily  of  the 
currem  sublibrary. 

Note  that  a  main  program  must  be  a  procedure  without  parammers,  and  that  <unit-name>  is  the 
idemifier  of  the  procedure,  not  a  file  specification.  The  main  procedure  is  not  checked  for 
parameters,  but  the  execution  of  a  program  with  a  main  procedure  with  parameters  is  undefined. 
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6JJ  The  Pinundtr  <recompilario««nwc» 

The  syntax  of  <rccoiBpitothi«»i|wc>  is: 

<ttnit_spco(*bodyHpccifladioii][,i.] 

This  paneneier  idb  the  linker  to  peifonn  a  consistency  check  of  the  endic  program  using  the 
hypodietical  recompilaiion  of  all  units  designated  in  the  <reran9ilation-spec>.  The  link  process 
in  this  instance  is  not  acnially  peifcnned. 

The  <unit_speo  is  a  list  of  unh-names  (wildcaids  are  allowed),  sepanted  by  conuna  (,)  or  plus 
(4-).  Each  umt-name  should  indude  an  option  to  indicate  if  the  body  or  spedficaiion  is  to  be 
hypothetically  compiled  (•spec  is  the  default). 


6JJ  Required  Recompilations 

If  the  consistency  check  found  that  recompilations  are  required,  a  list  of  required  recompUadons 
is  written  to  the  currem  ouput  file  or  to  a  text  file  if  the  •log  option  is  specified  (the  name  of 
the  text  file  is  indicated  in  the  log  file,  line  8).  The  list  will  indude  any  inoonsisiendes  detected 
in  the  library  and  lecompiladons  required  by  the  hypothetical  recompilations  spedfied  with  the 
options  •dedaratkNi  and  •body. 


The  entries  in  the  list  contain: 


1)  The  unit  name. 

2)  Indication  of  what  type  of  unit  (declaration  imit.  body  unit,  or  subunit). 

3)  If  the  unit  is  specified  as  recompiled  with  the  •declaration  or  •body  option,  it  is  marked 
with  "-R*". 

4)  The  environmenal  variable  of  the  sublibrary  containing  the  uniL 

In  the  recompilation  list  the  units  are  listed  in  a  recommended  recompilation  order,  consisiem  with 
the  dependendes  among  the  units. 


d.5.4  •searchlib 

•seardilib  <filc_name>  {,<llle-nanie>} 

The  •searddib  option  directs  the  Ada  Linker  to  search  the  spedfied  80x86  target  libraries  for 
objea  modules  in  order  to  resolve  symbol  references.  The  80x86  target  libraries  liM’  object  files 
will  be  searched  before  the  DACS  Run-Tiffle  System  (RTS)  library  nonnaOy  searches  for  nuMime 
routirres:  in  this  way  one  can  replace  the  standred  DACS  RTS  routines  with  custom  routines. 

The  •searchlib  option  is  also  intended  to  spedfy  libraries  of  modules  referenced  fiom  Ada  via 
pragma  INTERFACE. 
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Examples: 

S  adaJink  •Marchlib  interfSKC^Ub  p 

Links  the  sab(m>gnm  p.  resolving  referenced  symbols  flm  with  the  target  library  interface.lib 
and  then  with  the  standard  RTS  target  Ubrary. 


•stop Jrefiire-link 
•atop_bclbre_link 

The  •stopjbcfbrcjink  option  allows  the  user  to  introduce  assembleis  and  linkers  from  third 

parties  or~to  othtfwise  configure  the  link  to  suit  the  applicatian.  The  link  is  halted  with  the 

following  conditions: 

•  The  user  configurable  data  file,  <inain>-ucd.o,  is  produced  with  the  defeult  or  user  specified 
linker  option  values  included. 

•  The  elaboration  code  is  contained  in  the  <maiii>.elabcode.o  file. 

•  The  shell  script  file  that  comains  the  link  command  is  presem  and  has  not  been  executed.  The 
file's  name  is  <main>-Iink.com. 

•  The  temporary  Ada  object  file(s)  used  by  the  target  linker  are  produced.  These  objects  are 
linked  and  deleted  when  <main>-link.com  is  executed. 

•  With  ‘Selective Jink  the  objea  files  comprise  all  Ada  units  including  those  from  the  root 
library.  At  this  ^int  it  is  possible  to  disasemUe  the  "cut"  objea  files  using  •otgea  with  the 
disassembler. 

To  complete  the  link,  the  <main>  Jink.com  script  must  be  executed.  To  use  third  party  tools,  this 

file  may  have  to  be  modified. 


6J^  •options 
•options  <parainctei^ 

•options  allow  the  user  to  pass  options  onto  the  targa  linker. 
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6J.7  •library 

•library  <fllcHuine> 

•library  SadtJIbrary  (deteilt) 

The  •library  option  specifies  the  current  sublibnry.  from  which  the  linking  of  the  main  unit  will 
take  place.  If  this  option  is  not  specified,  the  sublibnry  specified  by  the  environmental  variable 
ada  Jibrary  is  used. 


•sdcctivc^link 

•selectIvcJink 

This  extrects  all  required  objea  modules  from  the  Ada  library  Oncluding  the  root  library)  and  cuts 
out  exactly  those  parts  that  are  actually  called,  in  order  to  make  the  resulting  target  program 
considerably  smaller.  If  a  program  uses  e.g.  PUT_UNE  as  the  only  routine  from  TEXTJO,  the 
contribytion  from  the  TEXTJO  objea  module  will  only  contain  PUT_LINE  (and  whatever  that 
needs).  Note  that  disassemblies  of  units  used  in  a  selective  link  normally  will  not  match  what  is 
linked,  because  of  the  cutting.  Such  disassemblies  may  though  be  obtained  by  disassembling 
directly  those  units  that  made  up  the  selective  link,  by  stopping  the  linking  before  the  targa  link 
phase  (•stop_bcforeJink).  making  disassemblies  using  •objea  and  then  resuming  the  link. 

Note  also  that  unused  constants  and  petmanem  variables  are  not  removed. 

Only  "level  1"  subprograms  may  be  removed.  Nested  subprograms  (that  are  not  called)  ate  to  be 
removed  during  compilation  using  the  •optimixe  optiott  Nested  subprograms  are  only  removed, 
if  the  routine  in  which  the  nesting  occurs  is  removed. 


6J.9  •(nojlog 

•log  [<file-speo] 

•nolog  (default) 

The  option  specifies  if  a  log  file  will  be  produced  from  the  from  erxl  linker.  As  default,  no  log 
file  is  produced.  If  <fiIe-speo  is  not  entered  with  •log  the  default  file  name  for  the  log  file  will 
be  link.log  in  the  currera  directory. 

The  log  file  contains  extensive  infonnation  on  the  results  of  the  link.  The  file  includes: 

•  An  elaboration  order  list  with  an  entry  for  each  unit  included,  showing  the  order  in  which  the 
units  will  be  elaborated.  Fdr  each  unit,  the  unit  type,  the  time  stamp,  and  the  dependencies  are 
shown  Furthermore,  any  elaboration  inconsistencies  will  be  report^ 

•  A  linking  summary  with  the  foQowing  information: 

•  Parameters  and  active  options. 

•  The  full  name  of  the  program  library  (the  currem  sublibrary  and  its  ancestor  sublibraries). 
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•  The  number  of  esch  type  of  di«gnn«rie 

■  A  tennination  message,  stating  if  the  Unkiiig  was  tenninated  successftiUy  or  unsuccessfully  or 
if  a  consequence  examination  was  tenninated, 

*  Diagnostic  messages  and  warnings  are  written  on  the  log  file. 


If  tecompilations  are  required  (as  a  result  of  the  consistency  check)  a  text  file  is  produced 
containing  exceipts  of  the  log  file.  The  name  of  this  text  file  is  written  in  the  log  file,  line  8. 


The  log  file  consists  of: 

•  Header  consisting  of  the  linker  name,  the  linker  veision  number,  and  the  link  time. 

•  The  elaboiatim  order  of  the  compilation  units.  The  units  are  displayed  in  the  order  elaborated 
with  the  unit  number,  compilation  time,  unit  type,  dependencies,  and  any  linking  errois. 

■  If  recompilations  are  required,  the  units  that  must  be  recompiled  are  listed  along  with  its  unit 
type  and  sutdibrary  level 

>  The  linking  summary  that  includes  the  main  unit  name,  the  program  library,  any  recompilations 
that  are  required,  arid  if  any  errors  or  warnings  occurred. 


6,5.10  •(nolroot.extract 
•roouextract 

•noroot.extract  (default) 

The  units  contained  in  the  Ada  system  library  supplied  by  DDC*1  have  been  extracted  and  inserted 
into  the  Sada.rootjib  OMF  Library,  thus  eliminating  extractions  from  the  system  library  at  link 
time  and  improving  link  performance. 

The  user  should  nonnaUy  not  modify  or  compile  into  the  Ada  system  library  supplied  by  DDC-I. 
If  however,  a  unit  is  compiled  into  the  Ada  system  library,  the  Sada_tootJib  will  no  longer 
match  the  Ada  system  library  and  *1001  extract  must  be  specified  in  or^r  to  link  fiom  the  Ada 
system  library. 


6J.11  -[noldebug 


•debug 

•nodebug  (default) 

The  -debug  option  specifies  that  debug  infonnation  is  generated.  The  debug  infonnation  is 
required  to  enable  symbolic  debugging.  If  -nodebug  is  specified,  the  Ada  linker  will  skip  the 
generation  of  debug  information,  thus  saving  link  time,  and  will  not  insert  the  debug  information 
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into  the  chosen  suUitevy.  thus  saving  disk  space.  Note  that  any  unit  which  should  be 
symbolically  debugged  with  the  DDC-I  Ada  Symbolic  Cross  Debugger  must  also  be  compiled  with 
the  -debug  option. 


6J.12  -(nolrts 

•rts  (default) 

•norts 

The  -rts  option  directs  the  Ada  Linker  to  include  the  appropriate  Run-Time  System  (RTS)  in  the 
link,  -norts  directs  the  Ada  Linker  to  exclude  the  RTS  in  the  link. 

The  ability  to  exclude  the  Run-Time  System  horn  the  link  allows  the  user  to  do  an  addititmal  link 
with  a  privtte  copy  of  a  custom  RTS.  The  Ada  Linker  may  report  unresolved  references  to  RTS 
routines,  but  will  still  produce  a  relocatable  objeo  file. 


6J.13  -rms 


-rms 

This  option  selects  the  Rate  Monotonic  Scheduling  Tasking  Kernel  (if  tasking  is  selected).  The 
default  is  to  use  the  Standard  Tasking  Kentel.  This  feature  is  supi^ed  as  an  option. 


dS.14  -(no]extract 

-extract  (default) 

-nocxtract 

This  option  to  the  linker  allows  the  user  to  specify  that  program  unit  objects  should  not  be 
extracted  from  the  Ada  program  library.  This  option  would  be  used  if  the  user  knows  that  many 
objects  have  not  changed  since  the  last  link  and  does  not  warn  the  linker  to  waste  time  extracting 
thra. 

To  use  this  feature,  the  user  should  modify  the  temi^ate  to  not  delete  unit  objea  files  after  a 
target  link  is  performed.  This  way  the  objea  files  remain  in  the  cunem  directory  (or  whereever 
the  user  dedttes  to  put  them).  On  subsequent  links  the  user  can  extiaa  objm  modules  of 
modified  units  from  the  Ada  library  using  the  standalone  DACS  extrao  tool.  A  new  targa  link 
can  then  be  perfonned  using  a  combination  of  newly  extracted  objects  and  the  objea  files  from 
previous  links  that  have  gone  unchanged.  This  cotdd  significantly  improve  linker  speed  when 
linking  programs  that  share  common  and  rarely  modified  libraries  and  when  relinking  programs 
that  have  had  only  a  few  units  modified. 
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6J.15  •tcnipiate 

•template  <file*nanie> 

•tem^e  $ada_template  (default) 

The  templaie  file  is  known  to  the  linker  via  the  environmental  variable  adajcmplatc.  DDC-I 
siq^ies  a  default  tem|daie  file  as  part  of  the  standard  release  system.  Please  refer  to  appcMx  H 
for  detailed  information. 


tL5Ji6  •npx 


•npx  (default) 

•Qonpx 

The  -npx  option  specifies  that  the  80x87  (8087,  80287.  or  80387)  numeric  coprocessor  is  used 
by  the  Ada  program.  When  -apx  is  specified,  the  80x87  is  initialized  by  the  task  initialization 
routine,  the  floating  point  stack  is  reset  during  exception  conditions,  and  the  80x87  context  is 
saved  during  a  task  switch. 


Configurable  Data 

A  16  bit  boolean  constaru  is  generated  by  the  Ada  Linker 


»  0 

»  1 


CO  NPX  USED 


boolean 


•  80x87  is  not  used 

•  80x87  is  used 


6J.17  -tasks 


•tasks  In] 

(defnilt  is  no  tasking) 

This  option  specifies  the  maximum  number  of  tasks  allowed  by  the  RTS.  If  specified,  n  roust  be 
greater  than  zero.  If  -tasks  is  specified  without  a  value  for  n,  n  defaults  to  10.  If  -tasks  is  not 
specified,  the  RTS  used  will  not  include  support  for  tasking.  If  -tasks  is  specified,  the  RTS  used 
will  include  suppoit  for  tasking. 

Ada  Interrupt  tasks  identified  with  pragma  INTERRUPT.HANDLER  need  not  be  included  in  the 
coum  of  maximum  number  of  tasks.  Tlie  main  program  must  be  coumed  in  the  maximum  number 
of  tasks.  Note  that  the  main  program,  which  may  unplicitly  be  coosukred  a  task,  will  not  nm 
under  control  of  the  tasking  kernel  when  -notasks  is  specified.  See  also  -mii  optkm. 


Configurable  Data 

For  -tasks,  the  linker  generates  the  following  configurable  data: 
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<3  MkX  taJM 


-  » 


_C»_TCM 


■  T«ak 

CoAtrol 

■lock* 

ITCM) 


It  -api  la 
aetlv*,  ■ 
avMtle  co> 
pncMaot 


Example: 

$  ada-link  •tasks  3  p 

•  Link  the  prejram  P.  which  has  at  most  3  tasks,  including  the  main  program. 


6J.18  •priority 
•priority  n 

•priori^  15  (default) 

The  •priority  option  specifies  the  default  priority  for  task  execution.  The  main  program  will  nin 
at  this  priority,  as  well  as  tasks  which  have  had  no  priority  level  defined  via  pragma  PRIORTTY. 
The  range  of  priorities  is  from  0  to  31. 

Priorities  can  be  set  on  a  per  task  basis  dynamically  at  run  time.  See  section  E.1  (Package 
RTS.EntryPoints)  for  more  details. 


Conflfurabtc  Data 


The  Ada  Linker  generates  the  following  constam  data: 


CD  PUaUTT 


Conjtmnt  -  ■ 


Example: 

S  aria  ,  link  •tasks  •priority  8  p 

•  Link  the  subprogram  P  which  has  the  main  program  and  tasks  naming  at 
defouU  priority  8. 
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6J.19  •time-slice 

•tinie_siice  [r]  (default  no  time  slicing  is  active) 

The  -time^slice  options  specifies  whether  or  not  time  slicing  will  be  used  for  tasks.  If  spedfied, 
R  is  a  dedmal  number  of  seconds  representing  the  default  time  slice  to  be  used.  If  R  is  not 
specified,  the  default  time  slice  will  be  1/32  of  a  second.  R  must  be  in  the  range  Duration'Small 
^  R  S  10  and  must  be  greater  than  or  equal  to  the  -tinier  linker  option  value.  Time  slicing  only 
applies  to  tasks  running  at  equal  priority.  Because  the  RTS  is  a  preemptive  priority  scheduler,  the 
highest  priority  task  will  always  tun  before  any  lower  priority  task.  Only  when  two  or  more  tasks 
are  running  at  the  same  priority  is  time  slicing  applied  to  e^  task. 

Tune  slicing  can  be  specified  on  a  per  task  basis  dynamically  at  run-time.  See  Section  E.1 
(Package  RTS.EntryPoints)  for  more  details. 

Time  slicing  is  not  applicable  unless  tasking  is  being  used.  This  means  that  the  -tasks  option 
must  be  used  for  -timc^slice  to  be  effective. 


Configurable  Data 

The  Ada  Linker  generates  the  following  dau; 


_co_Ti»«_ai.icE_osEa 

0  >110  tloM  illcin9 

1  -  Tiaa  slletnv 


CO  THa  SLXCX 


BOOIXAW 


«b«OtUf  iBfQT 


•  representing  the  number  Y  that  satisfies  Y  *  DURATION’SMALL  »  R 


Example: 

S  adaJlink  •tiine_siice  0.125  -tasks  p 

•  Specifies  tasks  of  equal  priority  to  be  time  sliced  each  eighth  of  a  second. 


6J1J10  -timer 
•timer  R 

-timer  0.001  (default) 

The  -timer  option  specifies  the  resolution  of  calls  to  the  Run-Time  System  routine  TIMER  (see 
the  Run-lime  System  Configuration  Guide  for  DACS-80x86  for  more  infoimaiion).  The  number. 
R.  specifies  a  decimal  number  of  seconds  which  have  elapsed  for  every  call  to  TIMER.  The 
default  TIMER  resolution  is  one  millisecond.  R  must  be  in  the  range  DURATION'SMALL<  R 
<  2. 
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Configivable  Data 


The  Ada  Linker  generates  the  following  16  bit  constant: 


_CD_TXWR 


iUMoluf  Int—t 


•  representing  the  number  Y  that  satisfies  Y  *  DURATION’SMALLaR 


•reserve-stack 
•reserve  stack  {n] 


The  •reserve_stack  option  designates  how  many  words  ate  reserved  on  each  task  stack.  This 
space  is  rese^ed  for  use  by  the  RTS.  which  does  no  checking  for  stack  overflow.  This  reserved 
space  also  allows  the  RTS  to  function  in  situatians  such  as  handling  a  storage  error  exception 
arising,  horn  stack  overflow. 

The  •reserve_stack  option  also  reserves  pan  of  the  main  program  stack  size,  specified  by  the 
linker  option  ~mp_stack_size. 


Configurable  Data 


The  Ada  Linker  generates  the  following  integer  constant: 


CO  aUXKVE  STACK 


Examples: 

S  adaJink  •reserve_stack  200  •tasks  p 

•  Reserve  200  words  from  each  stack  for  use  by  the  RTS. 


&5.22  •It-stack-size 

•lt_stack_siie  n 
•Itlstacklsiie  S00(default) 

The  •lt_stack_size  option  designates  the  library  cask  default  size  in  wonfs.  A  library  task  is 
formed 'when 'a  task  objea  is  declared  at  the  outermost  level  of  a  package.  Library  taidts  are 
created  and  activated  during  the  initial  main  program  elaboration.  (See  the  Ada  Reference  Manual 
for  more  details). 
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For  each  library  task,  the  representation  spec: 

FOR  Task_ob9ea'STORAGE_SIZE  USE  N: 

can  be  used  to  specify  the  library  task  stack  size.  However,  if  the  representation  spec  is  not  used, 
the  default  library  task  size  specified  by  -lt_stack_size  will  be  used. 

For  efficiency  reasons,  all  tasks  created  within  library  tasks  will  have  stacks  allocated  within 
same  segmem  as  the  library  task  stack.  Normally,  the  segmem  which  contains  the  library 
stack  is  allocated  just  large  enough  to  hold  the  default  lita^  task  stack.  Therefore,  one  must 
the  option  'It-stack-option  or  the  pragma  LT_SEGMENT_SIZE  to  reserve  more  space  withii 
segment  that  may  be  used  for  nested  tasks'  stacks.  (See  the  implementatian  dependem  pragma 
LT_SEGMENT_SI2  in  Section  F.l  for  mote  infonnatian). 

The  range  of  this  parameter  is  limited  by  physical  memory  size,  task  stack  size  allocated  during 
the  build  phase  of  the  link,  and  the  maximum  segmem  size  (64K  for  all  except  the  380^86 
protected  mode,  which  is  4  GB). 

Conflgurable  Data 

The  Ada  Linker  generates  the  following  integer  constant: 


CD  IT  STACK  SITE 


IWTtgCK 


Example: 

S  ada-link  •lt_suck_size  2048  -tasks  p 

•  Link  the  subprogram  P  using  a  2K  words  defoult  libiaiy  stack  size. 


6.5.23  -It-stack-size 
•lt_segment_size  n 

•lt_segtnent_size  (It-stack-size  *  20  +  exceptiotu.stack_space)  (default) 

This  parameter  defines  in  words  the  size  of  a  library  task  segment.  The  library  task  segmem 
contains  the  task  stack  and  the  stacks  of  all  its  nested  tasks. 

The  default  value  is  only  large  enough  to  hold  otw  default  task  stack.  If  •lt_stack_size  is  used  and 
specifies  a  value  other  than  the  default  value.  -It^segment^size  should  also  be  specified  to  be  the 
size  of  <task_stack_size>  + 

<total_of_nested.tasks_sizes>  -f 
<20_wotds_overhead>  + 
exception.stack.space. 

Note  that  the  task,  stack  size  specified  by  the  ’STORA(3E_size  can  be  representation  spec  or  by 
the  option  -It-suck-size. 

Dynamically  allocated  tasks  receive  their  own  segmem  equal  in  size  to  the  mp_segmeni;_size. 
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The  range  of  this  parameter  is  limited  by  physical  memory  size,  task  stack  size  allocated  during 
the  build  phase,  and  the  maximum  segmem  size  (64K  for  all  except  the  386/486  protected  mode, 
which  is  4  GB^ 


Configurable  Data 

The  Ada  Linker  generates  the  following  dau  smctuie: 


CD  IT  SKoan  szxz 


zmm 


Example: 

S  adaJHnk  -tt_segnMnt_size  2048  •tasks  p 

•  Link  the  program  P  using  a  library  task  segment  size  of  2K  words. 


6JJ4  -mp-stack-sizc 


•mp_stack_size  n 
•mplstacklsizc  8000  (default) 


The  'inp^stack^size  option  specifies  the  main  program  stack  size  in  words. 

The  range  of  this  parameter  is  limited  by  physical  memory  size,  tasdt  stack  size  allocated  during 
the  build  phase  (in  tasking  programs  only),  the  maximum  segmem  size  (64K  for  all  except  the 
386/486  protected  mode,  which  is  4  GB).  and  the  size  of  mp.segmem.size. 

Configurable  Data 


The  Ada  Linker  generates  the  following  dau  structures  for  nontasking  programs: 


CO  MP  STACK  SIZE 


IWTECER 


CD  MP  STACK 


HP.STACK_SIZX 
««erda  ot~ 
2£S£SSS^__ 


CO  MP  STACK  STAKT 


Hl«h«at  addr. 
et  MP  itaek 


For  tasking  programs,  the  Ada  Linker  generates  the  same  structures  but  limits  the  size  to  1024 
words.  Tlds  stack  is  only  used  for  the  execution  of  the  system  sanup  code  and  elaboration. 
At  main  program  activation,  a  segmem  for  the  main  program  equal  to  the  size  specified  by  • 
-mp_segment_sizc  will  be  allocated  from  the  dynamic  memory  pool  and  a  stack  for  the  main 
program  equ^  to  the  size  specified  by  'mp^stackjaize  wiD  be  allocated  from  the  memory 
pool.  ”  ” 
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Example; 

$  ada_link  •inp_stack_siie  1000  p 

•  Link  the  subprogram  P  with  a  stack  of  1000  words. 


6J25  •mp.segniem-sixe 


•inp_scgimnt_sixe  n 
•mpIsegmenCaitt  8100  (Defudt) 

The  •inp_scgineiit_si2e  option  specifies  the  size,  in  words,  of  the  segmem  in  which  the  main 
program  stack  is  aOocated.  The  default  setting  can  be  calculated  from  the  fonnula: 

mp_segmem_size  «  mp_stack_size  -t- 

overhead  (tasks  •  1)  * 

(overhead  -i-  task_storage_size) 

Normally,  the  main  program  segmem  size  can  be  set  to  the  size  of  the  main  program  stack. 
However,  when  the  main  program  contains  nested  tasks,  the  stacks  for  the  nested  tasks  will 
allocated  from  the  dau  segmem  which  contains  the  main  program  stack.  Therefore,  when 
main  program  contains  nested  tasks,  the  main  program  stack  segmem  must  be  extended  via 
•inp_seginent_size  optioa 

The  range  of  this  parameter  is  limited  by  physical  memory  size,  task  stack  size  allocated  during 
the  build  phase  (in  tasking  programs  only),  and  the  maximum  segmem  size  (64K  for  ail  except 
the  386/486  protected  mode,  which  is  4  GB). 

Note:  Dynamically  allocated  tasks  receive  their  own  segmem  equal  in  size  to  mp_segmem.size. 


Configurable  Data 

The  Ada  Linker  allocates  the  _CD_MP_STACK  (see  the  •inp_stack_siie  option)  within  a  daa 
segment  called  _CD_MP_STAac_SEGMENT: 


CD  wstacx  Stamm 


STACK 


m  stacx  STMtT 


mjnacx.szu 


sssx 


Example: 

S  ada-link  'tasks  •mp_scgniait_slze  32000  program_a 

Links  the  subprogram  PROGRAM^,  which  contains  tasks  nested  in  dm  main  program 
allocating  32,000  words  for  the  main  program  stack  segment 
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&5J6  -task-storage-siae 


•taak_stonige_size  n 
•tasklstoragelsiae  1024  (default) 

This  option  sets  the  default  stoiage  size  in  words  for  stacks  of  tasks  that  are  not  library  tasks. 
This  value  can  be  overridden  with  a  representation  claise. 

The  mge  is  limited  by  the  size  of  the  lt_segment_size  Of  it  is  a  subtask  to  a  library  tadt).  or  by 
mp_segment_size  Of  it  is  a  subtask  to  the  main  program). 


Configurable  Data 


The  Ada  Linker  generates  the  following  daa  structure: 


CD  TASK  STORMC  SIZE 


mTEOEK 


6^.27  •interrupt.entry^table 
•intciTupt_entry_table  L41 

The  •intcrTupt_cnti7_table  option  specifies  the  range  of  ituemipt  vector  numbers  used  by  the 
Ada  program  in  mterrupt  tasks. 

The  number.  L,  specifies  the  lowest  numbered  interrupt  handler.  The  number,  H.  specifies  the 
highest  luanbered  interrupt  handler.  The  range  for  low  and  high  interrupts  is  0  to  235. 


Configurable  Data 

If  •intemipt_cntry_table  is  specified,  the  Ada  Linker  will  generate  the  following  data  structure: 


CD  LOW  nizEiwarT 


COUSTMIT 


<l) 


.cD_iiqa_mnjuwn 


cowsTAirr 


tsi 


.CO_ZllTZlllU)VT_«BCTCIl 


words  cosorvwd 
for  Xotompc 

Jasssi _ 


If  the  user  ever  detects  unresolved  references  to  the  symbeds: 

_CD_LOW_INTERRUPT 

_CD_HIGH_INTERRUPT 

_CD_INTERRUPT_VECrOR 
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the  Ada  prognm  comains  sisndanl  kMenupc  usks  for  which  the  RTS  requires  the  above  daa 
stiucoire.  You  musi  relink  the  Ada  program  spedfyuig  the  -taremiptjmitry^table  opiioo. 

Exanqrie: 

$  adaJink  -tasks  •intcmipt_cn07_tablc  S40  p 

•  Links  the  subprogram  P.  which  hss  standard  Ada  inienupt  entries  numbered  S 
through  20. 


6JJ8  -{nolenablc-taak  -trace 

•enable jaskjtrace 
•noenabie_ti&_trace  (default) 

This  option  instructs  the  exception  handler  id  produce  a  stack  trace  when  a  task  terminates  because 
of  an  unhandied  exceptimi. 


Configurable  Data 


CD  1MCC  tUMtan  |  ■nnt»M 


>  0  •  tMk  traea  dlsablad 

<■  1  •  CMk  ttaea  anablad 


6JJ9  -exccption^space 

•exception..space  n 
•exccption_space  OaOh  (default) 

Each  stack  will  have  set  its  top  area  aside  for  exception  space.  When  an  exception  occurs,  the 
excqnion  handler  may  switch  stack  to  this  area  to  avoid  accidental  overwrite  below  the  stack 
bottom  (which  may  lead  to  protection  exceptions)  if  the  siae  of  the  remaining  pan  of  the  stack 
is  smaller  than  the  N  value.  Specifying  a  value  »0  will  never  cause  stack  switching.  Otherwise  an 
N  value  below  the  default  value  is  not  recommended. 


Configurable  Data 


CO  Kceftiou  sxMx  staoe  size  1  larEaiE 


Note  that  this  value  is  added  to  all  requests  for  task  stack  space,  thus  requiting  an  increase  in  the 
requirements  of  the  appropriate  segmM's  size 
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JO  •sign.on 

•SigDJM  (<ttiBg>] 

When  this  option  is  specified  the  linker  will  fenerate  code  (o  output  a  sign  on  message,  before 
the  Ada  elateiadon  is  initialed  and  a  sign  off  message  when  the  taiget  progiam  has  tenninated 
successfully.  If  the  program  tenninaies  with  an  uncaught  exception,  the  sign  off  message  is  not 
printed. 

The  sign  on  message  axmas  of: 

START  [<string^]  <progiam  name> 
and  the  sign  off  message 
STOP  [<string>]  <prognm  naine> 

The  <string>  may  contain  spaces,  e.g. 

•sigri-on  Test  3*  (remember  the  quotes). 

This  facility  is  very  useful  to  separate  output  liom  several  target  programs  nm  after  each  other, 
and  to  verify  that  a  program  that  produces  little  or  no  output  has  actually  been  loaded  and  run 
successfully. 
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APPENDIX  F  CF  THE  Ada  STANDARD 


The  only  allowed  implementation  dependencies  correspond  to 
implementationodependent  pragmas,  to  certain  machine-dependent 
conventions  as  mentioned  in  Chapter  13  of  the  Ada  Standard,  and  to 
certain  allowed  restrictions  on  representation  clauses.  The 
implementation-dependent  characteristics  of  this  Ada  isqslementation, 
as  described  in  this  Appendix,  are  provided  by  the  customer.  Unless 
specifically  noted  otherwise,  references  in  this  Appendix  are  to 
compiler  documentation  and  not  to  this  report. 
Implementation-specific  portions  of  the  package  STANDARD,  which  are 
not  a  part  of  Appendix  F,  are: 

package  STANDARD  is 

type  SHORT_INTEGER  is  range  -32_768  ..  32_767; 

type  INTEGER  is  range  -2_147_483_648  ..  2_147_483_647; 

type  LONG_INTEGER  is 

range  -16#8000_0000_0000_0000#  ..  16#7FFF_FFFP_FFFF_FFFF#; 

type  FLOAT  is  digits  6 

range  -16#0.FPFF_FF#E32  ..  16#0.FPFF_FF#E32/ 

type  LONG_FLOAT  is  digits  15 

range  -16#0.FFFF_FFFF_FFFF_F8#E256  ..  16#0.FFFF_FFFF_FFFF_F8#E256; 
type  DURATION  is  delta  2#1.0#E-14  range  -131_072.0  ..  131_071.0; 
end  STANDARD; 
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This  appendix  describes  the  implememaiion-dependem  characteristics  of  DACS-80X86™  as  lequiied 
in  App^ix  F  of  the  Ada  Reference  Manual  (ANS1/MIL-STD-181SA). 


F.1  Implementation-Dependent  Pragmas 

This  section  describes  all  implementaiion  defined  pragmas. 


F.1.1  Pragma  INTERFACE^^PELUNG 

This  pragma  allows  an  Ada  program  to  call  a  non-Ada  program  whose  name  contains  characters 
that  are  invalid  in  Ada  subprogram  identifiers.  This  pragma  must  be  used  in  conjunction  with 
pragma  INTERFACE.  i.e..  pragma  INTERFACE  must  be  specified  for  the  Ada  subprogram  name 
prior  to  using  pragma  INTERFACE.SPELLING. 

The  pragma  has  the  format: 

pragma  INTERF.ACE.SPELLINC  (subprogram  name,  string  literal): 

where  the  subprogram  name  is  that  of  one  previously  given  in  pragma  INTERFACE  and  the  string 
literal  is  the  exan  spelling  of  the  interfaced  subprogram  in  its  native  language.  This  pragma  is 
only  required  when  the  subprogram  name  contains  invalid  characteis  for  Ada  identifiers. 

Example: 

function  RTS_6et0ataSegiMnc  return  Integer; 
pragma  INTERFACE  (ASMS 6,  RTS  GetDataSegment) ; 

pragma  INTERFACE_S?EI.LZNG  (RTS^GctOataSegment,  ''RISMGS?GetDataSegaent’')  ; 

The  string  literal  may  be  appended  'NEAR  (or  TAR)  to  specify  a  particular  method  of  call  The 
default  is  'FAR.  This  suffix  should  only  be  used,  when  the  called  routines  require  a  near  call 
(writing  'FAR  is  however  harmless).  If  'NEAR  is  added,  the  routine  must  be  in  the  same  segmem 
as  the  caller. 


F.1.2  Pragma  LT-SEGMENT.SIZE 

This  pragma  sets  the  size  of  a  library  task  stack  segment 
The  pragma  has  the  format: 

pragma  LT.SEGMENT_SIZE  (T,  N); 


where  T  denotes  either  a  task  objea  or  task  type  and  N  designates  the  size  of  the  library  task 
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suck  segment  in  words. 


The  Ubraiy  usk’s  suck  segmem  defaults  to  the  size  of  the  Iibnio<  task  suck.  The  size  of  the 
library  task  suck  is  nonnally  specified  via  the  representation  clause  (note  that  T  must  be  a  task 
type) 


for  T'STORAGE_SIZE  use  N: 

The  size  of  the  libnry  task  suck  segment  detennines  how  many  tasks  can  be  created  which  are 
nested  within  the  libnry  task.  All  tasks  created  within  a  libnry  task  will  have  their  sucks 
allocated  from  the  same  segment  as  the  library  task  stack.  Thus,  pngma  LT_SEGMENT.SI2 
must  be  specified  to  reserve  space  within  the  library  task  suck  segmem  so  that  nested  tasks' 
stacks  may  be  allocated  (see  section  7.1). 

The  following  restrictions  are  places  on  the  use  of  LT.SEGMENT.SIZE: 

1)  It  must  be  used  only  for  library  tasks. 

2)  It  must  be  placed  immediately  after  the  task  object  or  type  name  declaration. 

3)  The  library  task  stack  segmem  size  (N)  must  be  greater  than  or  equal  to  the  library  task 
suck  size. 


F.IJ  Pragma  EXTERNALJ^AME 


F.1J.1  Function 

The  pragma  EXTERNAL.NAME  is  designed  to  make  permanem  Ada  objects  and  subprograms 
externally  available  using  names  supplied  by  the  user. 


F.UJ  Format 

The  format  of  the  pngma  is: 

pngma  EXTERNALJ4AME(<ada_entity>.<extetnal  name>) 
where  <ada_entity>  should  be  the  tume  of: 

•  a  permanem  object,  i.e.  an  objea  (rfaced  in  the  permanem  pool  of  the  compilation  unit  •  such 
objects  originate  from  package  speciflcatioiB  and  bodies  only, 

•  a  constant  object,  i.e.  an  objea  placed  in  the  constam  pool  of  the  compOation  unit  •  please 
note  that  scalar  constants  are  embedded  in  the  code,  and  composite  constants  are  not  always 
placed  in  the  constant  pool,  because  the  cmisura  is  not  considered  constam  by  the  com^Ier. 
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•  a  subprogram  name.  i.e.  a  name  of  a  subprogram  defined  in  this  compilation  unit  -  please 
notice  that  separate  subprogram  specifications  cannot  be  used,  the  code  for  the  subprogrm 
must  be  present  in  the  compilation  unit  code,  and  where  the  <extemal  name>  is  a  string 
specifying  the  external  name  associated  the  <ada_entity>.  The  <exteinal  names>  should  be 
unique.  Specifying  identical  spellings  for  different  <ada_entities>  will  generate  errors  at  compile 
and/or  link  time,  and  the  responsibility  for  this  is  left  to  the  user.  Also  the  user  should  avoid 
spellings  similar  to  the  spellings  generated  by  the  compiler,  e.g.  E_xxxxx_yyyyy.  P_xxxxx. 
C.xxxxx  and  other  internal  identifications.  The  target  debug  type  infonnation  associated  with 
such  external  names  is  the  null  type. 


F.IJJ  Restrictions 

Objects  that  are  local  variables  to  subprograms  or  blocks  cannot  have  external  names  associated. 
The  entity  being  made  external  ("public”)  must  be  defined  in  the  compilation  unit  itself.  Attempts 
to  name  entities  from  other  compilation  units  will  be  rejected  with  a  warning. 

When  an  entity  is  an  object  the  value  associated  with  the  symbol  will  be  the  relocatable  address 
of  the  first  byte  assigned  to  the  object. 


F.U.4  Example 

Consider  the  following  package  body  fragment: 

package  body  exantple  is 

subtype  scringlO  is  string  (1 .. 10) ; 

type  s  is 
record 

len  :  integer; 
val  :  stringlO; 
end  record; 

global_s  ;  s; 

Const_s  :  constant  stringlO  :■  ”1234567890”; 

pragma  EXTERNAL_NAME (global_S ,  ”GLOBAL_S_OBJECT" ) ; 
pragma  EXTERNAL_NAME (const_s,  "CONST_S”); 

procedure  handle  (...)  is 

end  handle; 

pragma  EXTEIurAL_NAME (handle,  "HANDLE^PROC”) ; 


end  example; 

The  objects  GLOBAL.S  and  CONST.S  will  have  associated  the  names  "GLOBAL.S.OBJECT" 
and  "CONST.S".  The  procedure  HANDLE  is  now  also  known  as  "HANDLE_PROC.  It  is 
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allowable  to  assign  more  than  one  external  name  to  an  Ada  entity. 


F.UJ  Object  Layouts 

Scalar  objects  are  laid  out  as  described  in  Chapter  9.  For  arrays  the  object  is  described  by  the 
address  of  the  first  element:  the  array  constrainKs)  are  NOT  pass^.  and  therefore  it  is 
recommended  only  to  use  arrays  with  known  constraiius.  Non-  discriminated  records  take  a 
consecutive  number  of  bytes,  whereas  discriminated  records  may  contain  pointers  to  the  heap.  Such 
complex  objeos  should  be  made  externally  visible,  only  if  the  user  has  thorough  knowledge  about 
the  layout. 


F.l  J,6  Parameter  Passing 

The  following  section  describes  briefly  the  fundamentals  regarding  parameter  passing  in  connection 
with  Ada  subprograms.  For  more  detail,  refer  to  Chapter  9. 

Scalar  objects  are  always  passed  by  value.  FOr  OUT  or  IN  OUT  scalais,  code  is  generated  to 
move  the  modified  scalar  to  its  destination,  in  this  case  the  stack  space  for  parameters  is  not 
removed  by  the  procedure  itself,  but  by  the  caller. 

Composite  objects  are  passed  by  reference.  Records  are  passed  via  the  address  of  the  first  byte 
of  the  record.  Constrained  arrays  are  passed  via  the  address  of  the  fust  byte  (plus  a  bimffset  when 
a  packed  array).  Unconstrained  arrays  are  passed  as  constrained  arrays  [dus  a  pointer  to  the 
constraints  for  each  index  in  the  array.  These  constraints  consist  of  lower  and  upper  bounds,  plus 
the  size  in  words  or  bits  of  each  element  depending  if  the  value  is  positive  or  negs^ve 
respectively.  The  user  should  study  an  appropriate  disassembler  listing  to  thoroughly  understand 
the  compiler  calling  conventions. 

A  ftmetion  (which  can  only  have  IN  parameters)  returns  its  result  in  register(s).  Scalar  results  are 
registers/float  registers  only;  composite  results  leave  an  address  in  some  registers  and  the  rest,  if 
any,  are  placed  on  the  stack  top.  The  stack  still  contains  the  parameters  in  this  case  (since  the 
function  result  is  likely  to  be  on  the  stack),  so  the  caller  must  restore  the  stack  poiruer  to  a 
suitable  value,  when  the  function  call  is  dealt  with.  Again,  disassemblies  may  guide  the  user  to 
see  how  a  particular  function  call  is  to  be  handled. 


F.1.4  Pragma  INTERRUPT-HANDLER 

This  pragma  will  cause  the  compiler  to  generate  fast  interrupt  handler  entries  instead  of  the  normal 
task  calls  for  the  entries  in  the  task  in  which  it  is  specified.  It  has  the  format: 

pragma  INTERRUPT.HANDLER; 

The  pragma  must  appear  as  the  flm  thing  in  the  specification  of  the  task  object  The  task  must 
be  specified  in  a  parage  and  not  a  procedure.  See  Section  F.6.2.3  for  mote  details  and  restrictions 
on  specifying  address  clauses  for  task  entries. 
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F.IJ  Pragma  MONITOR.TASK 


F.U.l  Function 

The  pragma  MON1TOR_TASK  is  used  to  specify  that  a  task  with  a  certain  structure  can  be 
handled  in  a  special  way  by  the  Run-Tune  Sys^.  enabling  a  very  eflicient  context  switch 
operation. 


F.UJ  Format 
The  format  of  the  pragma  is 
pragma  MONTTORJTASK; 

The  pragma  must  be  given  in  a  task  specification  before  any  entry  declarations. 


F.IJJ  Restrictions 


The  following  restrictions  apply  on  tasks  containing  a  pragma  MONTTOR.TASK  : 

•  Only  single  arxmymous  tasks  can  be  "monitor  tasks". 

•  Entries  in  "monitor  tasks"  must  be  single  entries  (i.e.  not  family  entries). 

•  The  task  and  entry  attributes  are  not  allowed  for  "monitor  tasks"  and  "monitor  task”  entries. 

•  The  <declarative  part>  shouTld  only  contain  declaration  of  objects;  no  types  or  nested  sturctures 
must  be  used. 

•  The  structure  of  the  task  body  must  be  one  of  the  folic  3: 

tMk  body  MOH_TASX  1* 

<doel«rsci^  p«rc> 
bo«ln 

<sC4t«aMnc  llso 
loop 

••loot 

«eeopt  OITKT  l<p4raMtar_liat>  (do 
Mdl ;  ~ 

or 

aeeapt  DnilY_2<p4raMC«t_ll«o  (do 
<aeat«Mac2llsc>  ~ 

•ndj ;  "" 

or 

tatBifiat* 

•od  aolaet; 

•nd  loop; 

•nd; 


where  each  entry  declared  in  the  specification  must  be  accepted  unconditionally  exactly  once. 
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c«ak  body  hON_TASX  la 
<daelaracl^  pacc> 
bagln 

<aeaeaawnt  llat> 
loop 

aeeapt  MOtl_CllTRr<paraMCar_ltat>[do 
<atataeMnt_liat>  ~ 

and] ;  ~ 

and  loop; 
and; 


where  the  task  only  has  one  entry. 

In  both  cases  tire  declarative  pans,  the  statement  lists  and  the  parameter  lists  may  be  empty. 
The  statement  list  can  be  arbitrarily  complex,  but  no  irested  select  or  accept  statements  are 
allowed. 

No  exception  handler  in  the  monitor  task  body  can  be  given. 

The  user  must  guarantee  that  no  exceptions  are  propagated  out  of  the  accepts. 


F.1,5.4  Example 

The  following  tasks  can  be  defined 

task  I.:st  IU1IDI.XII  is 

ptaqM  MONITOR_TXSK; 
antry  INSERT  (C^.CLCM  TTPEI  ; 
antry  RXHOVE(EUM:eut  CLEM  TYPE)  ; 
antry  1S_PRESENT(E«11:ELEm3^®>‘ 

RESOLT :  eut^BOOlXMl)  ; 

and  LI3T_BMIOIJ»; 

task  body  LXST.BRNDtXR  Is 
*dalina  list* 

bagln 

'Inleiallsa  list* 

salact 

aeeapt  INSERT (CL£M;eLEM_TYPE) do 
'Insart  In  list*  ~ 
and  INSERT; 
or 

aeeapt  REMOVE  (ELEM;  out  EUM_TYPE)do 
'find  In  list  and  raaova  freai  list* 
and  REMOVE 
or 

aeeapt  IS_FRESENT(EIXH;EUM  TYPE 

RES:  out  ioOLEMOdo 

*sean  list* 
and  IS^PRESENT; 
or 

tarmlnaca, 
and  salact 
and  MON  TASK; 


The  task  can  be  used 

task  typa  LXST.OSER  la 

and  I.IST_OSER; 

task  body  LIST.OSER  Is 
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b««in 

a«l«et 

LIST  BAmLCll.ZinCRrcrZMT  eLBMI; 

•Is* 

rats*  IllsnT_autOK; 

•nd  s*l«et;  ~ 
loop 

LIST_HMIDLER.  IMSOIT (MEX7_EIXM)  ; 
•nd  loop; 

•nd  LIST  OSSH; 


F.l^  Pragma  TASK_STORAGE_SIZE  (T.  N) 

This  pragma  may  be  used  as  an  alternative  to  the  attribute  TASK_STORAGE_SIZE  to  designate 
the  storage  size  (N)  of  a  particular  task  object  (T)  (see  section  7.1). 


FJI  Impleinentation'Dependent  Attributes 
No  implementation-dependent  amibutes  ate  defined. 


F J  Package  SYSTEM 

The  specifications  of  package  SYSTEM  for  ail  DACS-SOxSb  in  Real  Address  Mode  and 
DACS-80286PM  systems  are  identical  except  that  type  Name  and  constant  System_Name  vary; 


System  Name 


DACS-8086 
DACS-80186 
DACS-80286  Real  Mode 
DACS-80286  Proteaed  Mode 


iAPX86 

iAPXi86 

iAPX286 

iAPX286_PM 


Below  is  package  system  for  DACS-8086. 

paek*9*  Systwn  la 

cyp*  Mord  la  n*w  Inta^ar; 

typ*  DNord  la  n*«  lonq^lncapar; 

eyp*  0nal9n*dMord  xa  rang*  0..CSS3S; 

for  OnslgnodHord' SIZE  ua*  1(; 

typ*  byt*  la  rang*  0. .ZSS; 

for  byta'SIZE  ua*  •; 

aubcyp*  S*9Mneld  la  OnalgnadMocd; 

typ*  AddE*aa  la 

racord 

offa*t  ;  0nal9n*<fllocd; 
aaqaiant  :  SaqaMneZd; 

•nd  racord; 


aubtyp*  Priority  la  Znt*9*r  rang*  0..31; 
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typa  BaaM 

la  (lArXBB); 

SYSm  lUHB 

:  eonatant  UaaM 

«  lABXBB; 

STOlWa  OMZT 

:  eonatant 

-  IS; 

lOMORy  szzx 

:  eonatant 

•  1  04B  STS; 

HZ1I  nr 

:  eonatant 

•  -2  IsT  403  447-1; 

MAX“Z1IT 

:  eonatant 

-  2  l47  4S3  S47; 

tMX~DXSZTS 

:  eonatant 

-  13; 

tttX~HMITZSSA 

;  eonatant 

-  31; 

rzn  oiELTk 

;  eonatant 

•  2S1.0n-31; 

TtCK' 

:  eonatant 

•  0.000  000  123; 

typa  Zntarfaca  languapa  la 

(ASMS, 

BIM6,  CB6.  CBd^BCVnSE. 

ABM  ACT, 

BUI  ACr,  C  ACT.  e  BBVeBSB  ACT. 

ASM~liaACF, 

buTmoacf.  e~ NQAcr,  c~ ncvnsB''aoAcr); 

typ*  ExeaptionZd  la  zaeord 

tuilt_nuab*t  :  QaaigaadWocd; 
unlqu«_nuwh  ar  :  OnalgnadNetd; 
and  caeetd; 

typa  taakValua  la  naw  Znta«ac; 

typa  AeeTaakValua  la  aeeaaa  TaakValua; 
typa  SaaiaphoraVaXua  la  naw  Inta«ac; 

typa  Saawphoxa  la  raeecd 

eountar 
{irat 

laat 

SQHaxt 

and  caeord; 


:  Znta^at; 

:  TaakValua; 

:  TaakValua; 

:  SaaMphotaValua: 

••  only  uaad  In  IDS. 


ZnltSaaMphora  ;  eonatant  Samaphera  :>  Saaaphota' (!> 0,0.0); 


and  Syataa; 


The  package  SYSTEM  specification  for  DACS-80386PM  package  system  is: 

paekava  syataa  la 

typa  Word  la  na«  S)iort^Zntavar; 

typa  ONocd  la  naw  Zntavax; 

typa  gword  la  naw  ton9_Znta«ar; 

typa  OnalvnadWerd  la  ran9a  0..CSS3S; 

for  OnalgnadNord' SZZX  uaa  16; 

typa  OnalgnadOWocd  la  canqa  0 . .  IStFITF^rnTt; 

fet  OnalqnadDWerd' SZZE  uaa  32;  " 

typa  Byta  la  ranga  0..2SS; 

for  Byta'SZZE  uaa  S; 

aubtypa  BagaantZd  la  Onalgnadwerd; 

typa  Addraaa  la 

raeetd 

oZZaat  :  OnalvnadDNord; 
aavBMnt  :  SavaantZd; 
and  taeoxd; 


for  Addraaa  uaa 
racord 

offaat  at  0  ranya  0..31; 
aagwant  at  2  ran«o  0..1S; 
and  racord; 


aubtypa  Brlorlty  la  Znta9or  ranga  0..31; 
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cyp«  Mmm 

i«  (utxsacjm); 

sTSTtM  mm 

:  eoMtant  Wwmm 

• 

1APX3SS  tM: 

STOAACf  OMIT 

:  eonatant 

m 

1C; 

mHoar  iiza 

;  eonatant 

m 

ICCl  0000  OOOOC; 

ma  nt 

:  eonatant 

m 

>1S*?000  0000  0000  0000* 

MAX  xnt 

:  eonatant 

m 

isorrr  frrr  frrr  rrrrt; 

MAX~0ieZ7S 

:  eonatant 

m 

13; 

MAXjaURISSA 

;  eonatant 

• 

31; 

mn  DuxA 

:  eonatant 

2*1.0*B-31; 

TICK 

:  eonatant 

0.000_000_OC2_5; 

tff  lafttacmJLuqtimqm  la 

(AMC,  PIMC,  esc,  css  SSVBtSe, 

asM.Acr,  rui  act.  c  act,  c  sevsass  act, 

ASM.iioAcr,  »tM_iioAcr,  cjBQAer.  c^sevcnsEjiOAcr) 

typ«  excaptionXd  la  raeord 

unlt_ii«aibar  ;  OnalufiadOMecd; 
ual^a_niMibar  :  analpiiadowerd; 
and  raeord; 

typa  TaakValua  la  naw  Intagar; 

typa  AeeTaakValua  la  aeeaaa  TaakValua; 
eypa  SaoMpheraValua  la  naw  Intagar; 

typa  Saaaphora  la  raeord 

eountar 
flrat,  laat 
SOHaxt 

and  raeord; 


Intagar: 

TaakValua; 

SaaapheraValua; 

~  only  uaad  In  BOS. 


Inltsaataphera  ;  eonatant  laaaphera  :>  Saaiiphora*  (1. 0, 0. 0) ; 


and  Syataa; 


F.4  Representation  Clauses 

The  DACS-80x86''^  fiiUy  supports  the  'SIS  representation  for  derived  types.  The  representation 
clauses  that  are  accepted  for  non-derived  types  are  described  in  the  following  subsections. 


F.4.1  Length  Clause 

Some  remarks  on  implementation  dependent  behavior  of  length  clauses  are  necessary: 

■  When  using  the  SIZE  attribute  for  discrete  types,  the  maximum  value  that  can  be  specified  is 
16  bits.  For  DACS-80386PM/80486PM  the  maximum  is  32  bits. 

•  SIZE  is  only  obeyed  for  discrete  types  when  the  type  is  a  pan  of  a  composite  object,  e.g. 
arrays  or  records,  for  example: 

type  byte  is  range  0..255; 
tor  byte' size  use  8; 

sixteen_bits_allocated  :  byte;  one  word  allocated 
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•ight_bic_p«c^«lcMnt  :  array (0.. 7)  of  byta;  —  four  words  allocacad 
typ«  rac  is 
racord 

cl,c2  :  byta;  — ■  aight  bits  par  component 

and  racord; 


•  Using  the  STORAGE.SIZE  attribute  for  a  collection  will  set  an  upper  limit  on  the  total  size 
of  objects  allocated  in  this  coUeciion.  If  Anther  allocation  is  attempted,  the  exception 
STORAGE_ERROR  is  laised. 

•  When  STORAGE.SIZE  is  specified  in  a  length  clause  for  a  task  type,  the  process  stack  area 
will  be  of  the  specified  size.  The  process  stack  area  will  be  allocated  inside  the  "standanf  stack 
segment  Note  that  STORAGE.SIZE  may  not  be  specified  for  a  task  object 


F.4J  Enumeration  Representation  Clauses 

Enumeration  representation  clauses  may  specify  representations  in  the  range  of  •32767..-f32766  (or 
-16#7FFF..16#7FFE). 


F.4J  Record  Representation  Clauses 

When  representaticm  clauses  are  applied  to  records  the  following  restrictions  are  imposed; 

•  if  the  component  is  a  record  or  an  unpacked  array,  it  must  stan  on  a  storage  unit  boundary 
(16  bits) 

•  a  record  occupies  an  integral  number  of  storage  units  (words)  (even  though  a  record  may  have 
fields  that  only  deAne  an  odd  number  of  bytes) 

•  a  record  may  take  up  a  maximum  of  32K  bits 

•  a  component  must  be  specified  with  its  proper  size  (in  bits),  regardless  of  whether  the 
component  is  an  array  or  not  (Please  note  that  record  and  unpacked  array  components  take  up 
a  number  of  bits  divisible  by  16  (sword  size)) 

•  if  a  non>array  conponem  has  a  size  which  etpials  or  exceeds  one  storage  unit  (16  bits)  the 
component  must  start  on  a  storage  unit  boundary.  i.e.  the  cornponem  must  be  spedAed  as: 

component  at  N  range  0..16  *  M  -  1; 

where  N  specifies  the  relative  storage  unit  number  (0.1.„.)  from  the  beginning  of  the  record,  and 

M  the  required  number  of  storage  units  (1.2....) 

•  the  elements  in  an  array  cornponem  should  always  be  wholly  contained  in  one  storage  unit 

•  if  a  cornponem  has  a  size  which  is  less  than  oac  storage  unit,  it  must  be  wholly  contained 
within  a  single  storage  unit: 
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component  at  N  range  X  ..  Y; 

where  N  is  as  in  previous  paragrqjh.  and  O  <«  X  <«  Y  <s  15.  Note  that  for  this  restriction 
a  component  is  not  required  to  start  in  an  integral  number  of  storage  units  from  the  begiruiing 
of  the  record. 

If  the  record  type  contains  components  which  are  not  covered  by  a  component  clause,  they  are 
allocated  consecutively  after  the  componem  with  the  value.  Allocation  of  a  record  component 
wittout  a  componem  clause  is  always  aligrted  on  a  storage  unit  boundary.  Holes  created  bireause 
of  componem  clauses  are  not  otherv^  utilized  by  the  compiler. 

Pragma  pack  on  a  record  type  will  attempt  to  pack  the  components  not  already  covered  by  a 
representation  clause  (perhaps  none).  This  packing  will  begin  with  the  small  scalar  components  and 
la^r  components  will  follow  in  the  order  spedlied  in  the  record.  The  padcing  begins  at  the  first 
storage  unit  after  the  components  with  representation  clauses. 


F.4J.1  Alignment  Clauses 

Aligrunent  clauses  for  records  are  implemented  with  the  following  characteristics; 

•  If  the  declaration  of  the  record  type  is  done  at  the  outermost  level  in  a  library  package,  any 
aligrunent  is  accepted. 

•  If  the  record  declaration  is  done  at  a  given  static  level  higher  than  the  outermost  library  level, 
i.e.,  the  permanem  area),  only  word  aligtunetus  are  accepted. 

•  Any  record  object  declared  at  the  outermost  level  in  a  package  will  be  aligned  according 
to  the  alignment  clause  specifted  for  the  type.  Record  objects  declared  elsewhere  can  only  be 
aligned  on  a  word  boundary.  If  the  record  type  is  associated  with  a  different  alignment,  an 
error  message  will  be  issued. 

•  If  a  record  type  with  an  associated  alignment  clause  is  used  in  a  composite  type,  the  alignment 
is  required  to  be  one  word;  an  error  message  is  issued  if  this  is  not  the  case. 


FJ  Implementation-Dependent  Names  for  Implementation  Oependoit  Components 
None  defined  by  the  compiler. 

F.6  Address  Clauses 

This  section  describes  the  implementation  of  address  clauses  and  what  types  of  emities  may  have 
their  address  specified  by  the  user. 
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FAl  Oi^Mts 

Addms  clauses  are  supponed  for  scalar  and  composite  objects  whose  size  cm  be  detennined  at 
compile  time.  The  address  dause  may  denote  a  dynamic  value. 


FA.2  Task  Entries 

The  implementation  supports  two  methods  to  equam  a  task  enoy  to  a  hardware  inieirupt  through 
an  addiiss  clause: 

1)  Direa  transfer  of  control  to  a  task  accept  staiemem  when  an  imemipt  occurs.  This  fonn 
requires  the  use  of  pragma  INTERRUPT.HANDLER. 

2)  Mapping  of  an  imemtpt  onto  a  normal  coixUtional  entry  call.  This  form  allows  the  interrupt 
entry  to  be  called  from  other  tasks  (without  spectal  actions),  as  well  as  being  called  when 
an  imemipt  occurs. 


F.6J.1  Fast  Interrupt  Tasks 

Directly  transferring  control  to  an  accept  statemem  when  an  imemipt  occurs  requires  the 
implemenution  dependent  pragma  INTERRUPT.HANDLER  to  tell  the  compiler  that  the  task  is 
an  interrupt  handler. 


FA22  Features 

Fast  imerrapt  tasks  provide  the  following  features: 

•  Provide  the  fastest  possible  response  time  to  an  interrupt 

•  Allow  entry  calls  to  other  tasks  during  imemipt  servicing. 

•  Allow  procedure  and  function  calls  during  interrupt  servicing. 

•  Does  ix>t  require  its  stack  to  be  allocated. 

•  Can  be  coded  in  p»  '  with  other  declarations  so  that  desired  visiblity  to  appropriate  parts 
of  the  program  can  be  achieved. 

•  May  have  multiple  accept  statements  in  a  single  fast  interrupt  task,  each  mapped  to  a  differem 
imerrupL  If  more  than  one  interrupt  is  to  be  serviced  by  a  single  fast  interrupt  task,  the  accept 
statements  should  simply  be  coded  consecutively.  See  example  2  how  this  is  done.  Note  that 
no  code  outside  the  acc^  statements  will  ever  be  executed. 
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F.6JJ  Linritations 

By  using  the  fast  interrupt  feature,  the  user  is  agreeii^  to  (dare  certain  restrictions  on  the  task  in 

order  to  speed  up  the  software  response  to  the  intem^x.  Consequently,  use  of  this  method  to 

culture  interrupts  is  much  faster  than  the  normal  method. 

The  following  limitations  ate  placed  on  a  fast  interrupt  task: 

•  It  must  be  a  task  object,  not  a  task  type. 

•  The  pragma  must  appear  first  in  the  spedficadon  of  the  task  object 

•  All  entries  of  the  task  objea  must  be  single  entries  (no  families)  with  no  parameters. 

•  The  entries  must  not  be  called  from  any  task. 

•  The  body  of  the  task  must  not  contain  any  statettxnts  outside  the  accept  statementfs).  A  loop 
statemetu  may  be  used  to  enclose  the  access),  but  this  is  meaningless  because  tw  code  outside 
the  accept  statements  will  be  executed. 

•  The  task  may  make  one  entry  caU  to  another  task  for  every  handled  interrupt,  but  the  call  must 
be  single  ar^  parameteriess  and  must  be  made  to  a  normal  tasks,  not  armther  fast  iruerrupt 
task. 

•  The  task  may  only  reference  global  variables;  no  dau  local  to  the  task  may  be  defined. 

•  The  task  must  be  declared  in  a  library  package.  i.e..  at  the  outermost  level  of  some  package. 

•  Explicit  saving  of  NPX  sute  must  be  performed  by  the  user  within  the  accept  statemem  if  such 
state  saving  is  required. 


F.6.2.4  Making  Entry  Calb  to  Other  Tasks 

Fast  interrupt  tasks  can  make  entry  calls  to  other  normal  tasks  as  long  as  the  entries  are  single  (no 
indexes)  and  parameterless. 

If  such  an  entry  call  is  made  and  there  is  a  possibility  of  the  normal  task  ixx  being  ready  to 
accept  the  call,  the  entry  call  can  be  queued  to  the  normal  task’s  entry  queue.  Thb  can  be  forced 
by  using  the  normal  Ada  conditional  entry  call  construct  shown  below; 

accept  E  do 
selea 
T.E; 
else 

null: 

end  select; 
end  E; 

Normally,  thb  code  sequence  means  make  the  call  and  if  the  task  b  not  waiting  to  accept  it 
immediately,  cancel  the  caU  and  continue.  In  the  context  of  a  fost  interrupt  task,  however,  the 
semaruics  of  thb  construa  ate  modified  slightly  to  force  the  queuing  of  the  etury  call. 
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If  an  unconditional  entry  call  is  made  md  the  called  task  is  not  waiting  at  the  corresponding 
accept  statement,  then  the  intemipt  task  will  wait  at  the  entry  call.  Alternatively,  if  a  timed  entry 
call  is  made  and  the  called  task  does  not  accept  the  call  before  the  delay  er^res,  then  the  call 
will  be  dropped.  The  conditional  entry  call  is  the  preferred  method  of  making  task  entry  calls 
from  fast  intemipt  handlers  because  it  allows  the  intemipt  service  routine  to  complete  straight 
through  and  it  guarantees  queueing  of  the  entry  call  if  the  called  task  is  not  waiting. 

When  using  this  method,  make  sure  that  the  intemipt  is  included  in  the  •intemipt_entry_Uible 
specified  at  link  time.  See  Section  7J2.1S  for  more  deuuls. 


F.6JJ  Implementation  of  Fast  Interrupts 

Fast  intemipt  tasks  are  not  actually  implemerned  as  true  Ada  tasks.  Rather,  they  can  be  viewed 
as  procedures  that  consist  of  code  simply  waiting  to  be  executed  when  an  intemipt  occurs.  They 
do  not  have  a  state,  priority,  or  a  task  control  block  associated  with  them,  and  are  not  scheduled 
to  'nin"  by  the  run-time  system. 

Since  a  fast  intemipt  handler  is  not  really  a  task,  to  code  it  in  a  loop  of  somekiixl  is  meaningless 
because  the  task  will  never  loop;  it  will  simply  execute  the  body  of  the  accept  statemem  whenever 
the  intemipt  occurs.  However,  a  loop  construa  could  make  the  source  code  more  easily  understood 
and  has  no  side  effects  except  for  the  generation  of  the  executable  code  to  implement  to  loop 
construct 


F.6J.6  Flow  of  Control 

When  an  intemipt  occurs,  control  of  the  CPU  is  transferred  directly  to  the  accept  statemem  of  the 
task.  This  means  that  the  appropriate  slot  in  the  interrupt  vector  table  is  modified  to  contain  the 
address  of  the  corresponding  fast  interrupt  accept  statement. 

Associated  with  the  code  for  the  accept  sutemem  is 

at  the  very  begirming: 

code  that  saves  registers  and  sets  (E)BP  to  look  like  a  frame  where  the  imerrupt  return 
address  works  as  remm  address. 

at  the  very  end: 

code  that  restores  registers  followed  by  an  IRET  instruction. 

Note  that  if  the  interrupt  handler  makes  an  entry  call  to  armther  task,  the  intemipt  handler  is 
completed  through  the  IRET  before  the  rendezvous  is  actually  completed.  After  the  rendezvous 
completes,  normal  Ada  task  priority  rules  will  be  obeyed,  and  a  task  context  switch  may  occur. 

Normally,  the  interrupting  device  must  be  reenabled  by  receiving  End-Of-ImeiTupt  messages.  These 
can  be  sera  from  machine  code  insertion  statements  as  demonstrated  in  Example  7. 
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F.6J.7  Saving  NPX  Sutc 

If  the  intenupt  handler  will  perform  floating  poim  calculations  and  the  state  of  the  NPX  must  be 
saved  because  other  tasks  also  use  the  numeric  coprocessor,  calls  to  the  appropriate  save/itstore 
routines  must  be  made  in  the  statemem  list  of  the  accept  statemem.  These  routines  are  located 
in  package  RTS.EmryPoints  and  are  called  RTS_Store_NPX_State  and  RTS.Restore.NPX.State. 
See  example  6  for  more  information. 


F.6JL8  Storage  Used 

This  section  details  the  storage  requirements  of  fast  imerrupt  handlers. 


F.6.2.9  Stadt  Space 

A  fast  interrupt  handler  executes  off  the  stack  of  the  task  executing  at  the  time  of  the  interrupt 
Since  a  fast  imerrupt  handler  is  not  a  task  it  does  not  have  its  own  stack. 

Since  no  local  data  or  parameters  are  permitted,  use  of  stack  space  is  limited  to  procedure  and 
function  calls  from  within  the  interrupt  handler. 


F.6JL10  Run*Tittw  System  Data 

No  task  control  block  (TCB)  is  created  for  a  fast  interrupt  handler. 

If  the  fast  interntpt  handler  makes  a  task  entry  call,  an  entry  in  the  _CD_INTERRUPr_ VECTOR 
must  be  made  to  allocate  storage  for  the  queuing  mechanism.  This  table  is  a  nin-time  system  data 
smicture  used  for  queuing  interrupts  to  normal  tasks.  Each  entry  is  only  10  words  for  80386/80486 
protected  mode  compilers  and  S  words  for  all  other  compiler  systems.  This  table  is  created  by 
the  linker  and  is  constrained  by  the  user  through  the  linker  option  •intemipt_entry_table.  For 
more  information,  see  Section  F.6.2.1  on  linking  an  plication  with  fast  interrupts. 

If  the  state  of  the  NPX  is  saved  by  user  code  (see  Section  F.6.2.7),  it  is  done  so  in  the  NPX  save 
area  of  the  TCB  of  the  task  executing  at  the  time  of  the  interrupL  This  is  appropriate  because  it 
is  that  task  whose  NPX  state  is  being  saved. 


F.6J  Building  an  Application  with  Fast  Interrupt  Tasks 

This  section  describes  certain  steps  that  must  be  followed  to  build  an  application  using  one  or 
more  fast  interrupt  handlers. 
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F^.l  Source  Code 

The  pragma  INTERRUFT.HANDLER  which  indicates  that  the  interrupt  handler  is  the  fast  form 
of  interrupt  handling  and  not  the  normal  type,  must  be  placed  in  the  task  specification  as  the  first 
statement 

When  specifying  an  address  clause  for  a  fast  interrupt  handler,  the  offset  should  be  the  interrupt 
number,  not  the  offset  of  the  interrupt  in  the  iruenupt  vector.  The  segment  is  not  applicaUe 
(although  a  zero  value  must  be  specified)  as  it  is  not  used  by  the  compiler  for  interrupt  addresses. 
The  compiler  will  place  the  interrupt  vector  into  the  INTERRUFTVEfTTORTABLE  segment  For 
real  address  mode  programs,  the  interrupt  vector  must  always  be  in  segmem  0  at  execution  time. 
For  (notected  mode  programs,  the  user  specifies  the  interrupt  vector  location  at  build  time. 

Calls  to  RTS.Siore.NPX.State  and  RTS_Restore_NPX_State  must  be  included  if  the  state  of  the 
numeric  coprocessor  must  be  saved  when  the  fast  interrupt  occius.  These  routines  ate  located  in 
package  RTS.EntryPoints  in  the  root  library.  See  exam{rie  6  for  more  infonnation. 


F.6JJ  Compiling  the  Program 
No  special  compilation  options  are  required. 


F.6JJ  Linking  the  Program 

Since  fast  interrupt  tasks  are  not  real  tasks,  they  do  not  have  to  be  accounted  for  when  using  the 
•tasks  option  at  link  time.  In  fact,  if  there  are  no  normal  tasks  in  the  application,  the  program 
can  be  linked  without  'tasks. 

This  also  means  that  the  linker  options  •lt_stack_siw.  •It^segment^size,  'mp^segment^size.  and 
•task_storage_size  do  not  apply  to  fast  interrupt  tasks,  exi^  to  nore  that  a  fast  interrupT  task  will 
execute  off  die  stack  of  the  task  rurming  at  the  time  of  the  interrupt. 

If  an  entry  call  is  made  by  a  fast  interrupt  handler  the  interrupt  number  must  be  included  in  the 
•intetTupt_entryjable  option  at  link  time.  This  option  builds  a  table  in  the  run-time  system  dam 
segment  t^  handle  entry  calls  of  interrupt  handlers.  The  table  is  indexed  by  the  interrupt  number, 
which  is  bounded  by  the  low  and  high  interrupt  numbers  specified  at  link  time. 


F.6J.4  Locating/Building  the  Program 

For  real-address  mode  programs,  no  special  actions  need  be  performed  at  link  time;  the  compiler 
creates  the  appropriate  entry  in  the  INTERRUPTYECTTORTABLE  segment.  This  segment  must  be 
at  segment  0  before  the  first  interrupt  can  occur. 

For  protected  mode  programs  no  special  actitms  need  be  performed.  The  Ada  Link  automatically 
recognizes  Ada  interrupt  handlers  and  adds  them  to  the  IDT. 
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FA4  Exampici 

These  example  illusuate  how  to  write  fast  intemipt  tasks  and  then  how  to  build  the  application 
using  the  fast  intemipt  tasks. 


F.6.4.1  Example  1 

This  example  shows  how  to  code  a  fast  intemipt  handler  that  (toes  not  make  any  task  enny  calls, 
but  simply  perfonns  some  intemipt  handling  code  in  the  accept  body. 

Ada  source: 

with  System; 
package  P  is 

<po(entially  other  declaiations> 

task  Fast_rntemipt_Handler  is 
pragma  INTERRUPT^HANDLER: 
entry  E; 

for  E  use  at  (segmem  s>  0.  offset  s>  lO); 
end: 

<potentially  other  declarations> 


end  P; 

package  body  P  is 

<potentiaUy  other  declarations> 

task  body  Fasi.buenupt.Handler  is 
begin 

accept  E  do 

<handle  intemq}t> 
end  E; 
end; 


<potentially  other  declatations> 


end  P  ; 


with  P; 

procedure  Exampie.l  is 
begin 

<main  progiam> 
end  Exampie.l; 


Compilation  and  Unking: 
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S  ada  Exampk^l 

$  ada-link  Examfilc'l  !  Note:  no  other  tasks  in  the  system  in  this  example. 


F.6.4J  Example  2 

This  example  shows  how  to  write  a  fast  imcnupt  handler  that  services  more  than  one  interrupt. 


Ada  source: 

with  System; 
package  P  is 

task  Fast_lntetTupt_Handler  is 
pragma  INTERRUFT.HANDLER; 

entry  El: 
entry  E2: 
entry  E3: 

for  El  use  at  (segment  »  0.  offset  «>  5); 

for  E2  use  at  (segment  *>  0.  offset  »>  9): 

for  E3  use  at  (segment  «>  0.  offset  »  1 1): 

end; 

end  P; 

package  body  P  is 

task  body  Fast_ImerTupt_Handler  is 
begin 

accept  El  do 

<service  interrupt  S> 
end  El; 

accept  E2  do 

<service  interrupt  9> 
end  E2; 

accept  E3  do 

<service  interrupt  11> 
end  E3; 
end; 


end  P, 


Compilation  and  Linking: 
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S  ads  Example^! 

$  ada  Jink  'tasks  •  Exanipl«_2  #  assumes  application  also  has  nonnal  tasks  (not  shown) 


F.6.4J  Example  3 

This  example  shows  how  to  access  global  dau  and  make  a  precedure  call  from  within  a  fast 
intenupt  handler. 


Ada  source: 

with  System; 
package  P  is 

A  :  Integer. 

task  Fast_Intemjpt_HandJer  is 

pragma  INTERRUPT.HANDLER; 
entry  E; 

for  E  use  at  (segment  •>  0.  offset  *>  16#127#); 
end: 

end  P; 

package  body  P  is 
B  ;  -iteger. 

procedure  P  (X  :  in  out  Integer)  is 
begin 

X  :»  X  +  1: 
end: 

task  body  Fast_Intenupt.Handler  is 
begin 

accept  E  do 
A  :*  A  +  B: 

P  (A); 
end  E: 
end; 


end  P; 


Compilation  and  Linking: 

$  ada  Exampie_3 
$  adaJink  Example_3 
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F.6.4.4  Example  4 

This  example  shows  how  to  make  a  task  entry  call  and  force  it  to  be  queued  if  the  called  task 
is  not  waiting  at  the  accept  at  the  time  of  the  call. 

Note  that  the  application  is  linked  with  •tasks=2,  where  the  tasks  are  T  and  the  main  program. 
Since  the  fast  interrupt  handler  is  making  an  entry  call  to  T.  the  techniques  used  guarantee  that 
it  will  be  queued,  if  necessary.  This  is  accomplished  by  using  the  conditional  call  construa  in 
the  accept  body  of  the  fast  interrupt  haruller  and  by  including  the  interrupt  in  the  - 
interrupt_entry_table  at  link  time. 


Ada  source: 

with  System; 
package  P  is 

task  FastJntemipt.Handler  is 
pragma  INTERRUPT.HANDLER; 
entry  E; 

for  E  use  at  (segment  =>  0.  offset  =>  8); 

end; 

task  T  is 
entry  E; 
end; 

end  P; 

package  body  P  is 

task  body  Fast.Interrupt.Handler  is 
begin 

accept  E  do 
select 
T.E; 
else 

null; 

end  selea; 
end  E; 
end; 

task  body  T  is 
begin 
loop 
selea 
accept  E; 
or 

delay  3.0; 
end  select; 
end  loop; 
end; 

end  P; 
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Compilatiofi  and  Unking: 

S  ada  Exaniple_4 

$  adaJink  'taslu  2  •interrupt_entry_table  M  Exampie_4 


F4k4j;  Example  5 

This  example  shows  how  to  build  an  application  for  80386/80486  protected  mode  programs  using 
fast  interrupt  handlers. 


Ada  source: 

with  System: 
package  P  is 

task  Fast_InteiTupt_Handler  is 

pragma  INTERRUPT.HANDLER; 
entry  E; 

for  E  use  at  (segment  »  0.  offset  s>  17); 
end: 

end  P. 

package  body  P  is 

task  body  Fast.Interrupt.Handler  is 
begin 

accept  E  do 
null; 
end  E; 
end: 

end  P: 


Compilation  and  Unking: 

S  ada  Exampie^S 
S  ada-link  'tasks  •  Exampie^S 
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F.6.4^  Example  6 

This  example  shows  how  to  save  and  restore  the  state  of  the  numeric  coprocessor  from  within  a 
fast  interrupt  handler.  This  would  be  required  if  other  tasks  are  using  the  coprocessor  to  perform 
floating  poim  calculations  and  the  fast  interrupt  handler  also  will  use  the  coprocessor. 

Note  that  the  state  of  the  NPX  is  saved  in  the  task  corurol  block  of  the  task  executing  at  the  time 
of  the  interrupt. 

Ada  source: 

with  System; 
package  P  is 

task  Fast_Intetrupt_Haiuller  is 
pragma  INTERRUPT.HANDLER; 
entry  E; 

for  E  use  at  (segment  s>  o.  offset  =>  2S): 
end; 

end  P; 

with  RTS.EntryPoints; 
package  body  P  is 

task  body  Fasi_lntemipt_Handler  is 
begin 

accept  E  do 

RTS_EntryPoints.Store_NPX_State; 

<user  code> 

RTS_EntryPoints.Restore_NPX_State; 
end  E; 
end; 

end  P; 

Compilation  and  Linking: 

S  ada  Example  6 

S  ada_link  -npx  'tasks  •  Example j6 


F.6.4.7  Example  7 

This  example  shows  how  to  send  an  End-Of-Interrupt  message  as  the  last  step  in  servicing  the 
interrupt. 


Ada  source: 
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with  System: 
package  P  is 

task  Fast.Iiuerrupt_Handler  is 
pragma  INTERRUPT.HANDLER; 
entry  E; 

for  E  use  at  (segmem  •>  0.  offset  >>  S): 
end; 

end  P: 

with  Machine.Code:  use  Machine.Code: 
package  body  P  is 

procedure  Send.EOI  is 
begin 

machine.instiucdon’ 

(registerjmmediate,  m_MOV.  AL.  16#66#): 
machinejnstiuction’ 

(immediate.iegister.  m_OUT.  16#0e0#.  AL); 

end: 

pragma  inline  (Send_EOI): 

task  body  Fasi.IntetTupt_Handler  is 
begin 

accept  E  do 
<user  code> 

Send_EOI: 
end  E: 
end: 

end  P: 

Compilation  and  Linking: 

S  ada  Example^? 

$  adajink  'tasks  •  Exainplc_7 


F.6^  Normal  Interrupt  Tasks 

"Nomnal'*  intermpt  tasks  are  the  standard  method  of  servicing  interrupts.  In  this  case  the  intemipt 
causes  a  conditional  entry  call  to  be  made  to  a  nonnal  task. 


F.6J.1  Features 

Normal  interrupt  tasks  provide  the  following  features: 

1)  Local  dau  may  be  defined  and  used  by  the  imemipt  task. 
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2)  May  be  called  by  other  tasks  with  no  restrictions. 

3)  Can  call  other  nonnal  tasks  with  no  restrictions. 

4)  May  be  declared  anywhere  in  the  Ada  prognun  where  a  nonnal  task  declaration  is  allowed. 


F.6JJ1  Limitations 

Mapping  of  an  interrupt  onto  a  noimal  conditional  entry  call  puts  the  following  constraints  on  the 
involved  entries  and  tasks: 

1)  The  affected  emries  must  be  defined  in  a  task  objea  only,  txn  a  task  type. 

2)  The  entries  must  be  single  and  parametertess. 


F.6Jj  Implementation  of  Normal  Interrupt  Tasks 

Normal  interrupt  tasks  are  standard  Ada  tasks.  The  task  is  given  a  priority  and  runs  as  any  other 
task,  obeying  the  normal  priority  rules  and  any  time>slice  as  configured  by  the  user. 


F.&i.4  Flow  of  Control 

When  an  imerrupt  occurs,  control  of  the  CPU  is  transferred  to  an  interrupt  service  routine 
generated  by  the  spectricadon  of  the  interrupt  task.  Tlris  routine  preserves  the  registers  and  calls 
the  run*time  system,  where  the  appropriate  interrupt  task  and  entry  are  determined  from  the 
information  in  the  _CD_INTERRUIT_ VECTOR  table  and  a  condidonal  entry  call  is  made. 

If  the  interrupt  task  is  waiting  at  the  accept  sutement  that  corre^nds  to  the  interrupt,  then  the 
interrupt  task  is  scheduled  for  execudon  upon  return  from  the  imerrupt  service  routirre  arxl  the  call 
to  the  run-time  system  is  completed.  The  interrupt  service  routine  will  execute  an  DRET.  which 
reenables  interrupts,  and  execution  will  continue  with  the  imerrupt  task. 

If  the  interrupt  task  is  not  waiting  at  the  accept  statement  that  corresponds  to  the  imerrupt.  and 
the  interrupt  task  is  not  in  the  body  of  the  accept  statemem  that  corresponds  to  the  imerru^  then 
the  entry  call  is  automatically  queued  to  the  task,  and  the  call  to  the  run-time  system  is 
completed. 

If  the  interrupt  task  is  not  waiting  at  the  accept  statement  that  corresponds  to  the  imerrupc.  and 
the  interrupt  task  is  executing  in  the  body  of  the  accept  statemem  that  corresponds  to  the  interrupt, 
then  the  interrupt  service  routine  will  NOT  complete  until  the  interrupt  task  has  exited  the  body 
of  the  accept  statemem.  During  this  period,  the  iruemipt  will  not  be  serviced,  and  execution  in 
the  accept  body  will  continue  with  interrupts  disabicd.  Users  are  cautioned  that  if  from  within 
the  body  of  the  accept  statemem  corresponding  to  an  interrupt,  an  unconditional  entry  call  is  made, 
a  delay  statement  is  executed,  or  some  other  non-deterministic  action  is  invdced,  the  result  will 
be  erratic  ai  d  will  cause  non-deterministic  interrupt  response. 

Example  4  shows  how  End-Of-Imerrupt  messages  may  be  sem  to  the  imerrupting  device. 
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F.6JJ  Saving  NPX  State 

Because  nonnai  imemipt  tasks  are  standard  tasks,  the  state  of  the  NPX  numeric  coprocessor  is 
saved  automatically  by  the  nm-time  system  when  the  task  executes.  Therefore,  no  special  actions 
are  necessary  by  the  user  to  save  the  state. 


F.6JS.6  Storage  Used 

This  section  describes  the  storage  requirements  of  standard  interrupt  tasks. 

F.6J.7  Stack  Space 

A  normal  interrupt  task  is  allocated  its  own  stack  and  executes  off  that  stack  while  servicing  an 
interrupt.  See  the  appropriate  sections  of  this  User’s  Guide  on  how  to  set  task  stack  sizes. 


F.6J.8  Run-Time  System  Data 

A  task  control  block  is  allocated  for  each  normal  interrupt  task  via  the  -tasks  option  at  link  time. 

During  task  elaboration,  an  entry  is  made  in  the  run-time  system  .CDJNTERRUPT.VECTOR 
uble  to  "define'’  the  standard  imerrupt.  This  mechanism  is  used  by  the  nm-dme  system  to  make 
the  conditional  entry  call  when  the  interrupt  occurs.  This  means  that  the  user  is  responsible  to 
include  all  iraerrupts  serviced  by  interrupt  tasks  in  the  -inteiTupt_entry_table  option  at  link  time. 


F.6.6  Building  an  Application  with  Nonnai  Interrupt  Tasks 

This  section  describes  how  to  build  an  application  that  uses  standard  Ada  tasks  to  service 
interrupts. 


F.6.6.1  Source  Code 

No  special  pragmas  or  other  such  directives  are  required  to  specify  that  a  ask  is  a  normal  interrupt 
task.  If  it  contains  imerrupt  eruries,  then  it  is  a  normal  interrupt  task  by  default 

When  specifying  an  address  clause  for  a  normal  interrupt  handler,  the  offset  should  be  the 
interrupt  number,  not  the  offset  of  the  imerrupt  in  the  imerrupt  vector.  The  segmem  is  not 
applicable  (although  some  value  must  be  specified)  because  it  is  not  used  by  the  compiler  for 
interrupt  addresses.  The  compiler  will  ^ace  the  interrupt  vector  into  the 
INTERRUPTVECTORTABLE  segment  For  real  address  mode  programs,  the  interrupt  vector 
must  always  be  in  segmem  0  at  execution  time.  This  placemem  can  be  accomplished  by  specifying 
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the  address  to  locate  the  INTERRUPTVECTORTABLE  segment  with  the  loc86  command,  or  at 
nin  time,  by  having  the  startup  code  routine  of  the  UCC  copy  down  the 
INTERRUFTVECTORTABLE  segment  to  segment  0  and  the  compiler  will  put  it  there 
automatically.  For  (xotected  mode  programs,  the  user  spedfles  the  intemipt  vector  location  at 
build  time. 


F.6jS2  Compiling  the  Program 
No  s^ial  compilation  options  are  requited. 


F.6.6J  Linking  the  Program 

The  interrupt  task  must  be  included  in  the  'tasks  option.  The  link  options  •lt_stack_size.  — 
lt_segment_size.  -mp_segment_sue.  and  >task_storage_siae  apply  to  normal  interrupt  tasks  and 
must  be  sef  to  af^ptiate  valua  for  your  appOcation.  ~ 

Every  interrupt  task  must  be  accounted  for  in  the  •interrupt_entry_table  option.  This  option 
causes  a  table  to  be  built  in  the  run-time  system  dau  segmem  m  han^e  interrupt  entries.  In  the 
case  of  standard  interrupt  tasks,  this  table  is  used  to  map  the  interrupt  onto  a  normal  conditional 
entry  call  to  arxrther  task. 


F.6.7  Examples 

These  examples  illustrate  how  to  write  nonnal  interrupt  tasks  and  then  how  to  build  the  application 
using  them. 


F.6.7.1  Example  1 

This  example  shows  how  to  code  a  simple  normal  inrenupt  handler. 

Ada  source: 

with  System: 
package  P  is 

task  Notmal_Intertupt_Handler  is 
entry  E: 

for  E  use  at  (segmem  «>  0.  ofEset  *>  10); 
end: 

end  P; 

package  body  P  is 

task  body  Notmal_IntetTupt_Handler  is 
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begin 

accept  E  do 

<liandle  imeniipt> 
end  E; 
end; 

end  P: 

with  P; 

procedure  Exainpk.l  is 
bepn 

<main  progiam> 
end  Examfde.l; 


Compilation  and  Linking: 

S  ada  Examplc^l 

S  ada  Jink  •tasks  2  •intefTupt_cntry_tabic  10,10  Examplc_l 


F.6.72  Example  2 

This  example  shows  how  to  write  a  nonnal  intemipt  handler  that  services  more  than  one  intenupt 
and  has  other  standard  task  entries. 

Ada  source: 

with  System; 
package  P  is 

task  Nonnal.Task  is 

entry  El; 

entry  E2;  -  standard  entry 

entry  E3; 

for  El  use  at  (segmem  »  0.  offiset  *>  7); 
for  E3  use  at  (segmem  «>  0.  ofbet  »>  9); 

end; 

end  P; 

package  body  P  is 

task  body  Noimal_Task  is 
begin 
loop 
selea 

accept  El  do 

<service  intemipt  7> 
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end  El; 
or 

accept  E2  do 

<standanl  rendezvous> 
end  E2: 
or 

accept  E3  do 
<service  intenupt  9> 
end  E3: 
end 

end  loop; 

end  Nonnal_Task; 
end  P; 

Conqiilation  and  Linking: 

S  ada  Example^! 

S  adaJink  ‘tasks  •intcrrupt_cntry_tabie  7,9  Exanipic_2 


F.6.7J  Exanqdc  3 

This  examfte  shows  how  to  build  an  application  for  80386  protected  mode  programs  using  nonnal 
interrupt  handlers. 


Ada  source: 

with  System; 
package  P  is 

task  Normal_Internipt_Handler  is 
entry  E; 

for  E  use  at  (segment  «>  0,  offset  »>  20); 
end; 

end  P; 

package  body  P  is 

task  body  Noimal_Inienupt_Handler  is 
begin 

accept  E  do 
null; 
end  E; 
end; 

end  P; 
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Compilation  and  Linking: 

S  ada  Examplc_3 

S  adaJink  ‘tasks  •interrupt_cnti7_Tabie  M,20  Exampie_3 


F^7.4  Example  4 

This  example  shows  how  an  End*OMnienupt  message  may  be  sem  to  the  inieiniptmg  device. 

Ada  source: 

with  System; 
package  P  is 

task  Nosmal^Znterrupt^Mandler  is 
entry  eT  ” 

for  E  use  at  (segment  >>  0,  offset  ■>  7) ; 

end; 


end  P; 

with  Machine^Code;  use  Machine_Code; 
package  body  P  is 

procedure  Send_EOZ  is 
begir.  ~ 

fflachine_inst ruction ' 

(register^iansdiate,  m_MOV,  AL,  16*66*); 
machine^instruction'  ” 

(imnediate^register,  m_OUT,  16*0e0*,  AL) ; 
end;  ” 

pragma  inline  (Send_E01); 

task  body  Normal_Interrupt_Handler  is 
begin  *”  ” 

accept  E  do 
<user  code> 

Send_EOZ ; 
end  E;~ 

end; 


end  P; 


Compilation  and  Linking: 

S  ada  Example  j4 

S  ada-Jink  -tasks  •intcrnipt_entry_table  7,7  Examplej* 
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F.6J  Interrupt  Queuing 

DDC-I  provides  a  useful  feature  that  allows  task  entry  calls  made  by  interrupt  handlers  (fast  and 
normal  variant)  to  be  queued  if  the  called  task  is  not  waiting  to  accept  the  call,  enabling  the 
interrupt  handler  to  complete  to  the  IRET.  What  may  not  be  clear  is  that  the  same  interrupt  may 
be  queued  only  once  at  any  given  time  in  DDC-Ps  implementation.  We  have  made  this  choice 
for  two  reasons: 

a)  Queuing  does  not  come  for  free,  and  queuing  an  interrupt  more  than  once  is  considerably 
more  expensive  than  queuing  just  one.  DEXT-I  feels  that  most  customers  prefer  their 
interrupt  handlers  to  be  as  fast  as  possible  and  that  we  have  chosen  an  implementation  that 
balances  performance  with  functionality. 

b)  In  most  applications,  if  the  servicing  of  an  interrupt  is  not  performed  in  a  relatively  short 
period  of  time,  there  is  an  unaccepuble  and  potentially  dangerous  situation.  Queuing  the 
same  interrupt  more  than  once  represents  this  situation. 

Note  that  this  note  refers  to  queuing  of  the  same  interrupt  more  than  once  at  the  same  time. 
Different  interrupts  may  be  queued  at  the  same  time  as  well  as  the  same  interrupt  may  be  queued 
in  a*  sequential  manner  as  long  as  there  is  never  a  situation  where  the  queuing  overlaps  in  time. 

If  it  is  accepuble  for  your  application  to  queue  tfu:  same  interrupt  more  than  once,  it  is  a 
relatively  simple  procedure  to  implement  the  mechanism  yourself.  Simply  implement  a  high 
priority  agent  task  that  is  called  from  the  interrupt  handler.  The  agent  task  accepts  calls  from  the 
interrupt  task  and  makes  the  call  on  behalf  of  the  interrupt  handler  to  the  originally  called  task. 
By  careful  design,  the  agent  task  can  be  made  to  accept  all  calls  from  the  interrupt  ta^  when  they 
are  made,  but  at  the  very  least,  must  guarantee  that  at  most  one  will  be  queued  at  a  time. 


F.6.9  Recurrence  of  Interrupts 

DDC-I  recommends  the  following  techniques  to  ensure  that  an  interrupt  is  completely  handled 
before  the  same  interrupt  recurs.  There  are  two  cases  to  consider,  i.e.  the  case  of  fast  interrupt 
handlers  and  the  case  of  normal  interrupt  handlers. 


F.6.9.1  Fast  Interrupt  Handler 

If  the  fast  interrupt  handler  makes  an  entry  call  to  a  normal  task,  then  place  the  code  that 
reenables  the  interrupt  at  the  end  of  the  accept  body  of  the  called  task.  When  this  is  done,  the 
interrupt  will  not  be  reenabled  before  the  rendezvous  is  actually  completed  between  the  fast 
interrupt  handler  and  the  called  task  even  if  the  call  was  queued.  Note  that  the  interrupt  task 
executes  all  the  way  through  the  IRET  before  the  rendezvous  is  completed  if  the  entry  call  was 
queued. 

Normally,  erxl-of-interrupt  code  using  Low_Level_IO  will  be  presem  in  the  accept  body  of  the  fast 
interrupt  handler.  This  implies  that  the  end-of-intetrupt  code  will  be  executed  before  the 
rendezvous  is  completed,  possibly  allowing  the  interrupt  to  come  in  again  before  the  application 
is  ready  to  handle  it 

If  the  fast  inierrapt  handler  does  not  make  an  entry  call  u>  another  task,  then  placing  the 
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end-of-iiuemipt  code  in  the  accept  body  of  the  bst  inienupt  task  will  guarantee  that  the  inienupt 
is  completely  serviced  before  another  intenupt  happens. 


F.6.9J  Normal  Interrupt  Handler 

Place  the  code  that  reenaUes  the  intemipt  at  the  end  of  the  accept  body  of  the  normal  interrupt 
task.  When  this  is  done,  the  intemipt  will  not  be  reenabled  before  the  rendezvous  is  actually 
completed  between  the  noimal  intemipt  handler  and  the  called  task  even  if  the  call  was  qi^ed. 
Even  though  the  intemipt  "comfrietes"  in  the  sense  that  the  IRET  is  executed,  the  intenupt  is  not 
yet  reenabled  because  the  rend^ous  with  the  noimal  task’s  intemipt  entry  has  not  been  made. 

If  these  techniques  are  used  for  either  variam  of  interrupt  handlers,  caution  must  be  uken  that 
other  tasks  do  not  call  the  task  entry  which  reenables  intemipts  if  this  can  cause  adverse  side 
effects. 


F.7  Unchecked  Conversion 

Unchecked  conversion  is  only  allowed  between  objects  of  the  same  ’’size”.  However,  if  scalar  type 
has  differeru  sizes  (packed  and  unpacked),  unchecked  conversion  between  such  a  type  and  another 
type  is  accepted  if  either  the  packed  or  the  unpacked  size  fits  the  other  type. 


F.8  Input/Output  Packages 

In  many  embedded  systems,  there  is  no  need  for  a  traditional  I/O  system,  but  in  order  to  suppon 
testing  and  validation.  DDC-I  has  developed  a  small  terminal  oriented  I/O  system.  This  I/O  system 
consists  essentially  of  'TEXTJO  adapted  with  respect  lo  haixUing  only  a  terminal  and  not  file  I/O 
(file  I/O  will  cause  a  USE  error  to  be  raised)  and  a  low  level  package  called 
TERMINAL.ORIVER.  A  BASICJO  package  has  been  provided  for  convenience  purposes, 
forming  an  interface  between  TEXT.IO  and  'TERMINAL.DRIVER  as  illustrated  in  the  following 
figure. 


rtxi  lo 

BASIC  10 

TBiwnuL  Dazvn 
(B/W  Intcrfaesi 

The  TERMINAL.DRIVER  package  is  the  only  package  that  is  target  dependent,  i.e.,  it  is  the  only 
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package  that  need  be  changed  when  changing  communications  conuoUets.  The  actual  body  of  the 
TERMINAL.DRIVER  is  written  in  assembly  lai^uage  and  is  pan  of  the  UCC  modules  DlIPUT 
and  DIIGET.  The  user  can  also  call  the  terminal  driver  loutines  directly.  i.e.  from  an  assembly 
language  routine.  TEXT.IO  and  BASIC.IO  are  written  completely  in  Ada  and  need  not  be 
changed. 

BASIC.IO  provides  a  mapping  between  TEXT.IO  corurol  characters  and  ASCI  as  follows; 
TEXTJO  ASai  Character 


UNE.TERMINATOR 

ASGLCR 

PAGE  TERMINATOR 

ASai.FF 

FILE.TERMINATOR 

ASQLSUB  (CTRJL/Z) 

NEWSLINE 

ASai.LF 

The  services  provided  by  the  terminal  driver  are: 

1)  Reading  a  character  from  the  communications  port.  Get.Character. 


2)  Wridng  a  character  to  the  communications  port.  Put.Character. 


F.8.1  Pk..kage  TEXTJO 


The  specification  of  package  TEXTJO: 

praqaa  p«««; 
with  BASIC^IO; 

with  lO.cxcxrriaNS; 

p«ck«9«  teXT^IO  Ij 

typ«  riU_T7PE  is  llaicad  prlvacs; 

typs  riLE_MOOE  IS  tni_riLE.  OOT_riIi); 

cyps  COONT  Is  rang*  0  . .  INTEGER' LAST; 

subcypa  PCSITIVE_COONT  Is  COONT  canGa  1  ..  COUNT' LAST; 

ONBOONOEO:  conscanc  COONT;*  0;  --  llna  and  paga  lanGtb 

--  oMX.  slxa  at  an  IntaGat  oucput  tlald  2#....* 
subcypa  riELO  Is  INTEGER  tangs  0  . .  3S; 

subcypa  NOMaER_BASE  is  INTEGER  tanga  2  ..1C; 

typa  TT»E_3ET  la  (LONER_CASE,  0PPER_CA3E>  ; 

pragma  PAGE; 

"  rila  ManagasMnt 


procadura  CREATE 

(FILE 

:  in  out 

FILE  TTPE; 

NODE 

:  in 

FILE~MOOE 

^OT  FILE; 

NAME 

:  in 

STRriio 

FORM 

); 

:  in 

STRING 

••• 

pceeadurs  OPEN 

(FILE 

:  in  out 

FILE  TYPE; 

NODE 

:  in 

FILE*  NODE; 

NAME 

:  in 

STRING; 

1 
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>; 


In 


STKXIMS 


preeaduc*  CU>se  (FltX 
pteeaduM  DtLXn  (FXLX 
proeaduta  MCSCT  (FIU 
HQOe 

pceeadura  USST  (FXU 


tn  out  FXXX  met  ; 
In  out  FXLS'TTPt) ; 
tn  out  FILS'ntE; 
Ln  FXLK  MOOft) : 
tn  out  FXXX  TTtt); 


funetton  HOOK 
funetton  MMS 
funetton  FOm 


(FXtX 

(FXXX 

(FItX 


tn  FItX  TYFC) 
tn  FILE~r»ei 
tn  FIU~TTPK) 


totutn  FXX£_HOOe; 
catun  STKXM6; 
ratum  snUNC; 


funetton  IS_OPeM<FXtx  :  tn  FXU_TTPt  ratunt  MOUtM; 


pra^M  FA6E; 

—  control  of  default  input  and  output  ftlaa 


pcoeadura  SET  XMPOT  (FILE  :  tn  FILE  TTPEI ; 
pcocadura  set^OOTFOT  (FILE  :  tn  FZIE.TTPE) : 


funetton  STAI10MD_DIF0T  ratutn  FILE.TTPE; 
function  STAMOMID  ODTFOT  catum  FILE  TYPE; 


funetton  antKENT  XHPOT  ratutn  FILE  type; 
funetton  CniUlEIR'~OaTPOT  ratutn  F1LE~TYPE; 


praqma  FASE; 

"  spaetfleatton  of  Itna  and  page  longthi 


proeaduta  SET_LIIIE^LEMCTB 
proeaduta  SE7_LIHE^teMQtB 


(FILE  ;  in  FXLE  TYPE; 

TO  :  tn  COOMT); 

(TO  :  tn  COONTl ; 


proeaduta  SET_FAG£^LEMSTB 
procaduea  SET_FA(a^LEM6Ta 


(FILE  :  tn  FILE  TYPE; 

TO  !  in  COOHT); 

(TO  ;  tn  COOMT); 


function  LIME_I.DiaTE 
function  LIME  LENOTB 


(FILE  !  tn  F1LE_TYPE) 
ratutn  COONT;  ~ 
ratutn  COONT; 


function  PA(3_LOMiTB 
function  PA(Z  lenoth 


(FILE  :  in  riLE_TYPE) 
ratum  COOMT;  ~ 
return  COOMT; 


pragma  FACE; 

"  Column,  Lino,  and  Fago  Control 

procaduea  MEN  LIME  (FILE  :  tn  FILE  TYPE; 

SFAClMG  :  tn  POSITIVE  COOMT  :>  1); 
proeaduta  MEN^LINE  (SFAClMG  :  in  FOSITIVE~COONT  1)  ; 

proeaduta  SKIP  LIME  (FILE  :  tn  FILE  TYPE; 

SPACIMG  :  in  POSITIVE  COOMT  :•  1) ; 
proeaduta  SXIF_LIM£  (SPACING  ;  tn  POSXT=VE~COOMT  :>  1); 

funetton  END  OF  LIME  (FILE  :  tn  FILE  TYPE)  return  BOOLEAN; 
funetton  EMO^OF'lIME  ~  ratutn  BOOLEAN; 

proeaduta  MEM^PASE  (FILE  :  tn  FILE.TYPE) ; 
pcoeadura  HEn'pagE;  ~ 

proeaduta  SXIP_PAae  (FILE  :  tn  FILE.TYPK) ; 
procaduea  SXIPJPAGE; 

function  tmj3r_nat  (FILE  :  tn  FILE.TYPE)  ratum  BOOLEAN; 
funetton  EMDjOF~PA6E  ratum  BOOLEAN; 

function  END  OF  FILE  (FILE  :  in  FILE  TYPE)  return  BOOIEAN; 
function  EMD*'OF~FXLE  ~  ratum  BOOLEAN; 
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praeaUar*  SR  cOL  «mx  ;  ta  rsu  TTK; 

lo  ;  la  Msxixve  ooon); 

preea«lta  SKtJXL  <TO  ;  la  tOSXTIVE_COaiiri  ; 

precaduca  SR  UME  (rXU  :  la  RU  TTtS: 

to  :  la  tOSXTZW  OOORI ; 
preeaduta  SR.LXME  (to  :  la  POSRXVt'cOORI  ; 

foaetlan  COL  (rXXX  :  la  rxu_TYPK> 

racasn  VOSXTXVS^OOOn; 
fuaecian  COl  cacusa  SOSRXVirooaR; 

fwietlen  LXNE  (rXU  :  la  rxujmt) 

caCtin  tosXTXvsTooaR; 
faaetlen  LXn  taCttsa  tOSRXVE_OOaR; 

Cuaetloa  PA«  (FXU  :  la  rxu;_Tm) 

tatatn  POSITIVE jOOOR; 
fuaetlen  PASE  racum  POSXTXVE^COOR; 

ptavM  PAR; 

Charaetar  Input-Outpac 

proeaduta  GR  (FXU  :  In  rXU_TVPE;  ITEM  :  out  CEAAACTElt)  ; 

pcecadura  6R  (  ~  XXIM  :  out  CEAAACTEK); 

ptoeaduxa  POT  (FILE  :  in  FXLE_TTPE;  ITEM  :  la  ClAMACTEX): 

procadura  POT  (  ~  Xmt  :  la  CEAAACTEA)  : 

—  Strlao  laput-Output 

proeadura  SET  (FXU  :  la  FXU_TrPE;  ITEM  ;  out  CEAHACTEA) ; 

ptoeaduxa  SR  (  ~  XTEH  :  out  (aAAACTEA) ; 

ptoeaduxa  POT  (FXU  :  la  FXU.TTPE;  ITEM  :  la  CEAAACTEKI ; 

ptoeaduxa  POT  (  ~  ITEM  :  la  (3UAACTEA); 

ptoeaduxa  SR  LXME  (FXU  ;  la  FXU  TYPE; 

ITEM  :  out  STEXMS; 

USt  :  out  MATOML); 

ptoeaduxa  SR  LINE  (XTU  :  out  STAINS: 

LAR  :  out  MATOAAll; 

ptoeaduxa  POT  LINE  (FXU  :  la  FXU  TYPE: 

ITEM  :  la  STAIHSl; 
ptoeaduxa  POT_LINE  (ITEM  :  la  STAINS): 

pxasM  PA(ai: 

••  Ganaxle  Paeliaga  fox  Input-Output  of  Intogat  Typaa 
ganaxlc 

typa  NOM  l«  xanoa  o; 
paekava  INTESEA  10  la 


OBFAOLT  WXOTE 

FXEU 

:«  MOM'NXOTB; 

oefaolt'aase 

NOMBEA.BASE  :«  10; 

ptoeaduxa  SR 

(FXU 

la  FXU_TYPE; 

ITEM 

out  ROM: 

HXOTI 

la  FXELO  0); 

ptoeaduxa  SR 

(ITEM 

eut  MOM: 

NXOTE 

la  FXELO  :•  0); 

ptoeaduxa  POT 

(FXU 

la  FXU  TYPE; 

ITEM 

la  MOM; 

NXOTI 

la  FXELO  OCFAOLT  MSOTB; 

BASE 

la  NOMEA^^BASS  :•  l«rAOLT_BASE)  ; 

ptoeaduxa  POT 

(REM 

la  BOM:  " 

WXOTA 

la  FXELO  :•  OBFAOLT  NXDXB; 

BAR 

la  NOMBEA.BASB  WAOLT_BASE); 

ptoeaduxa  SR 

(FROM 

la  STAINS; 

ITEM 

out  MOM; 
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LEST 

:  Ottt 

POSITIVE) ; 

prtsoduxo  POT  (TO 

:  Ottt 

snuas; 

XTn 

la 

MOM: 

BEEE 

la 

WMERJMSE 

•ltd  zman  lo.- 


ocnun,x_tsn) ; 


pC*«M  rMB; 

am*cic  taekadM  lot  Input -Output  of  Raoi  Typoa 
puaotie 

typo  mH  is  digit*  O; 
paekago  noax_XO  la 


DEFEDLT  FORE  : 

FIELD 

m 

2; 

OEFEOLT'eFT  : 

FIELD 

•  MOM' DIGITS  - 

1; 

DEFEOLXJEXP  : 

FIELD 

- 

3; 

ptoeoduto  SET 

(FILE 

:  la  FILE  TYPE 

ptocodttto  SET 

ITEM 

non 

(ITEM 

out  MDM; 

:  la  FIELD  :> 

:  out  ROM; 

0); 

non  :  la  riXLD  :>  0); 


ptoeoduto  POT 

(FILE 

ITEM 

FORE 

EFT 

EXP 

ptoeoduto  POT 

(ITEM 

FORE 

EFT 

EXP 

ptoeoduto  GET 

(FROM 

ITEM 

LAST 

ptoeoduto  POT 

(TO 

ITEM 

EFT 

EXP 

and  rxoft;  XO; 


la  FILE  TYPE; 
in  MOM;* 

In  rZELB  :>  WAOLT  FOKE; 
in  FIELD  0EFMLT~ kFT; 

In  FIELD  DEFEOLT" E»I; 

in  HDM;  ' 

la  FIELD  :>  OEFEOLT  FORE; 
in  FIELD  !-  DEFAOLT~ EFT; 
la  FIELD  DErEOLT~E»); 

in  SnXMQ; 
out  MOM; 
out  POSITIVE); 
out  smxMa; 

In  MOH; 

in  FIELD  ;m  DEFEOLT  EFT; 
in  FIELD  DEFEOLT^EXP) 


pragM  PESE; 
ganatle 

typo  IRM  la  dolta  o; 
paeliago  FIXED  10  la 


OEFEOLT  FORE  ; 

FIELD 

-  NON' FORE; 

OEFEOLT'eTT  : 

FIELD 

-  NOM'EFT; 

DEFEOLT~EXP  : 

FIELD 

«  0; 

ptoeoduto  GET 

(FILE 

:  in  FILE_TYPE; 

ITEM 

:  out  MOM; 

non 

:  la  FIELD  0); 

ptoeoduto  GET 

(ITEM 

:  out  MM; 

non 

:  la  FIELD  0)  ; 

ptoeoduto  POT 

(FILE 

la  FILE  TYPE; 

ITEM 

la  mm;~ 

FORE 

in  FIELD  OEFEOLT  FORE; 

EFT 

la  FIELD  OBrEDLT~ EFT; 
in  FIELD  :>  OEFEOLT~EXP) ; 

ptoeoduto  POT 

(ITEM 

la  MOM; 

FORE 

la  FIELD  OEFEOLT  FORE; 

EFT 

in  FIELD  DEFEOuT EFT; 
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S»  :  in  rxns  SCTMLT.CVt; 

proendnn  OR  (IHOM  :  In  STIOM; 

XTBI  :  out  MM; 

UkJT  :  out  tMrmtl; 

ptocndurn  VOT  (TO  :  out  STUM; 

XT»  :  in  MM; 

ATT  :  In  mu  :>  DOTtOtT  *R; 
■»  :  in  mu  :•  HrULT.m; 

•nd  raXD_ZO; 


pn«M  SMB; 

••  Onnnrle  Saekapn  foe  Xnpwf~^CMt  of  BaoMorntlon  Tjpoa 
gonoele 

eypo  IMM  la  (oi; 
pnekofo  IMMMTZOll_XO  la 

OCTMR.T  ■XBTl  :  mU  0; 

0ErAm.T3sBTTXM  ;  TTPt_SR  :>  attOtjCASB; 

proeodttso  OKI  (FXU  :  In  rxu.TTtK;  XTBI  :  out  UKm): 
proeodnso  OR  (  XTBI  :  eat  OMMI; 

pceeoduco  SOT  (FXU  :  FXU.TTSC; 

ZTBI  ;  in  BIQM; 

VZBTS  ;  in  FXBU  ;>  ORWIT  NZen; 

SR  ;  la  rm_SR  ;•  ORAOLT'sRTXMI  ; 

proeaduro  SOT  (XTBI  :  In  BRJmT  ~ 

•ZBTS  :  la  FXBU  :>  ORUtT  NXOTB; 

SR  :  la  TTSB.SR  :>  OEFMt.T~SBTTXMI  ; 

preeadare  fiR  (FMM  :  In  STUM; 

XTBK  :  out  BMM; 

LMT  :  out  SOSXTXVB); 

praeadura  SOT  (TO  :  out  STUM; 

XTBI  :  la  BMM; 

SR  :  in  TtnjKt  :*  ORAOIT.SBTTXMI  ; 

and  noMMTXOH^XO; 
prapaw  SASB; 

—  Bxeaptlena 

RATOS  BUMS  :  axcaptlon  ranoOMa  XO  BXCERXOM.SXATOS^BBIIOB; 
MOOS  dwOS  :  oneoptlea  eonoaMa  ZO  BXCBmONS.MOOS.BSMB; 
MAMe'bwmK  :  oxeaptlen  raaaaaa  Xo'eXCBRXOMS.RAW.BIUWK; 
OSB  BIWM  :  aacaptlan  ranoMa  XO~BXCBSTXa«S.asB.BIIMM; 
DBVXCX.BMIOK  :  axeaptlan  mnaaMa  XO^BXCBSTXOMS.OBViesjBRMR; 
BM  BSnOK  :  axeaptlan  ranaaaa  ZO~BXeBSTZaHS.BM^BBMM; 
DATA  BmoR  :  axeaptlan  ranaMa  XO'bxcBRXOMS.SATA.BBMB; 
LATOOT.tMIOR  :  axeaptlan  ronoMa  XeTBXCESTXaMS.UTOOT.EBMR; 

prapaw  papa; 
prlvnta 

type  FXU_tTSB  la 
raeecd  ~ 

rt  :  XRBOBIl  -1; 
and  raeaed; 

and  TBR.XO; 
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FJJ  Psduce  lO^CEFTlONS 

The  spedficaikn  of  the  package  IO_EXCEFnONS: 


paexa««  zo^txeemein  is 


SIMM  tmOM 

MOOS  Bmoii 

NMB  nitOR 
MB  imm 
MvicB  BMee 
BMD  Baaoii 

Mn  BSMIl 
lATOOS  BMtOit 


•xeaptloa; 

•sesptleo; 

mesptton; 

Mcaptlen; 

•waptlon; 

Mcaptlea; 

mesptlea; 

aaeaptloa; 


FA3  Package  BASIC  JO 

The  Reification  of  package  BASICJO: 


with  ZO_BXCB»TiaHS.- 
packaya  BASZC^ZO  la 

typa  eaunt  la  ran^a  0  . .  Intaqar* last; 

aubtypa  paaltlva_eount  la  eeuat  saaya  1  ..  eouat'laat; 


fuaetloa  9at_laca«ar  racatn  striae; 

—  Skips  aay  laadlae  blaaka,  llaa  tat«laatera  or  paga 

—  tasalaators.  lhaa  caada  a  plus  or  a  aaaus  sign  It 

—  praaaat,  thaa  taa«la  aecerdUtag  to  tho  syntax  of  aa 

—  latogar  litoral,  ahieh  aay  ba  baaod.  Storos  la  itaai 

—  a  striae  eontalalae  aa  optional  alga  and  aa  latogor 
••  litoral. 

••  Tho  axcaptlen  MTA^IMOR  la  ralsad  If  tha  soquaaea 

—  of  eharaetors  doas''aot  eorraapond  to  tbo  syntax 

—  doaerlbod  abotro. 

—  Tha  axeaptlon  OV^diROR  la  ralsad  If  tho  flla  toralaator 
la  road.  This  noaaa  that  tha  starting  aaqnoaea  of  aa 

~  latogor  has  not  boon  0Mt. 

—  Hota  that  tha  eharaetor  tarsunatlag  tha  oparatloa  anst 
ba  avallabla  for  tho  aoxt  got  oporatlon. 

fuaetloa  got^roal  rotum  string; 

—  Corrosponda  to  got_iatogor  oxeopt  that  It  roads  aeeordlng 

—  to  tho  syntax  of  a^coal  litoral,  which  nay  bo  basod. 


function  got_onuBMratlon  rotum  string; 

—  Corraaponda  to  got_iatogor  oxeopt  chat  It  roads  according 
~  CO  tho  syntax  of  an  Idaatlflor,  whoro  uppor  and  lower 

— '  eaao  loccars  are  oqnlvalonc  to  a  eharaetor  litoral 

—  laelndlng  tho  aposcrephoa. 
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fmetlm  ««c_lt«i  (lanytli  :  la  latafw)  fM«n  atxiaf; 

—  iMda  •  •trtnv  (cm  eh*  evrcMC  IIm  mi4  m«cm  it  la 
••  ItM.  X(  ciM  catMlaiBf  BMbac  of  ekasaetMa  m  tka 

—  auccaac  liaa  la  laaa  chaa  laafth  ebaa  oalf  tkaaa 

—  ebacaetaca  aca  cacucaad.  Tba  llaa  tacalaacor  la  aac 
~  aklppad. 

pceeaduca  pat_ltM  (ItM  :  la  atclaf); 

—  X(  tba  laagth  of  tba  atclag  la  gcMtar  tbM  tba  aactMt 

—  MclaM  llaa  (Uaalaagth),  tba  aaeaptlaa  uurOCTJDMK 

—  la  calaad. 

—  Xf  tba  atclag  daaa  aot  (It  m  tba  oaccMt  Um  a  llaa 

—  tatalaatoc  la  oatpnt.  tbM  tba  ItM  la  aatpac. 

—  llaa  aatf  paga  iMgtba  -  UM  14.3.3. 

pceeadura  aat_llaa_laagth  (to  :  la  eaaatl; 

pceeaduca  aat_paga_laagth  (to  :  la  eoaat); 

.(unction  lino_lMgth  catuen  oount; 

(unction  pago_lMgth  ratum  count; 

—  Oparationa  on  coluaaa.  llnaa  and  pagan  •  MW  14.3.4. 

pcocaduca  na«_llna; 
precadura  aklp_llaa; 

(unction  and.o(_llno  catuen  boolaan; 
pcocaduca  naajpaga; 
pcocaduca  aklp_paga; 

(unction  ond_o(_paga  catuen  boolaan; 

(unction  ond_o(_,(lla  catuen  boolaan; 

pcocaduca  aatjeol  (to  :  In  poaltlaajeount) ; 

pcocoduco  aat_llna  (to  :  la  poaltloo_eo«at); 

(unction  col  catuen  poaltlva_eouat; 

(unction  lino  cotuca  poaltlva_eottnt; 

(unction  paga  cotuca  poaltlva^couat; 

—  Cbacaetac  and  atclng  pcoeaducaa. 

—  Coccoapoada  to  tbo  pcoeaducM  doflaod  la  MW  14.3.4. 

pcocoduco  gatjBbacaetac  (ItM  :  out  cbacaatac): 

pcocaduca  got_atclng  (ItM  :  Mt  atclng); 

pcocaduca  gat_llno  (ItM  :  Mt  atclag; 

laat  :  Mt  natucal); 

pcocaduca  put_ehacaetac  (ItM  ;  la  ehacaetaci; 
pcocaduca  put^atclag  (ItM  :  la  atclag); 
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preeaduM  patella*  (ttaa  :  la  atrlag); 


—  aaeaptloaa : 


osB  mo* 

aaeapciea  raai 

Maa  SO  MCl*fIO**.eas  mo*; 

oevxac  mo* 

aMaptlaa  raai 

■Ma  zo  ne»Tso«s.oevzes  cm*; 

em  SUM* 

axeaptlea  raaj 

xMa  xe_ixe»Ro*s.m  taio*; 

BhxX  smoK 

aaeaptlea  raai 

MMX  XO  esemzoHS.aan  saso*; 

LhTOOt  mo* 

axeaptlea  rani 

XMa  zo  caennous.ukion  cm*; 

aad  SMZe  XO; 


FA4  Psckafe  TERMINAL.DRIVER 

The  spedficttion  of  package  TERMINAL.DRIVER: 


paekap*  miHZllAL.DlUVSa  la 

pteeadura  pat_ehaxaetaa  (eh  :  la  ehaeaetarl; 
preeadara  gat_eharaetar  (eh  :  eat  ehaeaetart; 
private 

ptaqaa  laearSaea  (hSMSl.  put_eharaetarl ; 

prapM  lataeraea_apalllap  (put_ehaeaetar.  *01ZP0T?put jchataetar* ) ; 
pxapM  intartaea  (&SM<,  «ae_eharaetaxl ; 

peagna  lnear<aea^tpallla«  («at_eharaietar<  *01iaKr?tat_eharaetar*)  ; 
aad  mMlMU..DiiXvn; 


Packages  SEQUENTULJO  and  DIRECT  JO 

The  specifications  of  SEQUENTIALJO  and  DIRECTJO  are  specified  in  (he  ARM: 

Since  files  are  not  supported  the  subprograms  in  dteae  units  itaise  USE_ERROR  or 
STATUS_ERROR. 
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FA6  PKkafB  LOW^EVEUIO 

The  spedficttion  of  LOW_LEVELJO  (16  bio)  is: 


with  SyttMi; 

pMka««  WM_um_IO  It 

tubtyp*  port^tddtMt  It  Syttf  .BHtlgatdWogd; 

typ*  It  iMM  lat«««t  CM««  •Ut..U7; 

typ*  ll3te_XS  it  nan  tatapar; 

preeatfara  taadjcaatralidavtaa  :  la  pact_adStaaa; 

data  :  ta  Syacaa.Sytal; 

—  aaalgaad  •  bit  aatity 

praeadura  aaad_eantxal (davtea  :  la  pert_addrata; 

data  :  la  syttf  .oatigaadbetd) ; 

—  uatlpaad  1(  bit  aatity 

pceeadttta  aaad_eeattol (davlea  :  la  pact_addraaa; 

data  :  la  ll^la_di; 

•-  tlpaad  •  bit  aatity  ~ 

procadura  taad^eeatrol (davica  :  ta  poet^addrata; 

'*  data  :  la  ll_te_lCI  ; 

—  algaad  1(  bit  aatity  ~  “ 

procadura  raealua_eeatrel(daviea  :  la  port_addraaa; 

~  data  :  out  Syataa.tytal ; 

—  uaalpaad  •  bit  aatity 

procadura  racalvo_coatrol (daviea  ;  la  part_addraaa; 

**  data  :  out  SyataM.OatlpaadHord) ; 

—  uatlgaad  XC  bit  aatity 

procadura  raealva_cootroX (davtea  ;  la  port_addraaa; 

~  data  :  out  XX_le_S>; 

••  tlpaad  •  bit  aatity 

procadura  raealva_eoatroX (daviea  :  ta  port_addrass; 

**  data  :  out  XX_le_X<); 

•>  slgaad  XC  bit  aatity 

prlvata 

prapaa  laXlaa(sand_eeatroX,  raeatva^eoatroX); 
and  LON  LCVKL  ZO; 


Tha  apaelfleatlon  of  LON_LSVCL_XO  (32  blta)  la: 

with  SYSTCM; 

packaga  LON_LBVSL_IO  la 

aubtypa  port_addcaaa  la  SyataN.OaalgaadNocd; 

typa  XX_le_t  la  aaw  abort_latapar  raapa  -X2t..X27; 

typa  XX^le^XC  la  aaw  aberc.latapar; 

typa  XX~le_32  la  aaw  latapar; 

procadura  aaad_eootreX (daviea  :  la  pert^addcaaa; 

~  data  :  la  SyatoN.Syta); 

—  uaalpnad  •  bit  aatity 

procadura  aand_eaatroX (daviea  :  la  port_addcaaa; 

^  data  :  la  Syatw.aaalpaadHord) ; 
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ttMifiMd  1(  bit  Mtlty 

pcooAdun  (davtM  :  in  p*rejiUdtms: 

:  la  Syat«a.aaalgaatfMec4); 

—  ttaatpaad  12  blc  aatlty 

pceea4ura  aaa<l_eaaerel  (davlea  :  la  pavt^addtaaa; 

daca  :  la  ll_ia.S); 
algaad  •  bit  aaticy  ~ 

paoeadasa  saad_eoatxel (davlea  :  la  paat^addraas; 

data  :  la  ll_lo.l(); 

—  algaad  1<  bit  aatlty  ~ 

paaeadura  aandjooataol (daalea  :  la  paat^addcaaa; 

data  :  la  ll_la_32>; 

—  algaad  32  bit  aatlty  ' 

paaeadura  aaealva_eaatrel (davlea  :  la  pact_addraaa; 

~  data  :  aat  Syataa.bytai; 

—  uaalgaad  •  bit  aatlty 

paaeadura  aaeal«a_eeatral (daalea  :  la  part_addeaaa; 

data  :  aut  Syataa.Oaalgnadbaad) ; 

—  uaalgaad  1C  bit  aatlty 

paaeadura  raealva^eantrel (daalea  :  la  part_addraaa; 

~  data  :  aut  Syataa.OaalgnadDNaed) ; 

—  uaalgaad  32  bit  aatlty 

paaeadura  raealva_eaneral (davlea  :  la  pert_addraaa; 

~  data  :  aut  ll_la_St; 

—  algaad  •  bit  aatlty  ~ 

praeadura  raealva_eantral<daalea  :  la  part^addraaa; 

~  data  :  aut  ll_le_lS); 

••  algaad  1C  bit  aatlty 

praeadura  raealva_eaaeral (davlea  :  la  part^addraaa; 

'  data  :  aut  ll_la_12); 

••  algaad  32  bit  aatlty 


prlvata 

paagaa  lallaa<aaad_eaatral,  raealva_eeatral) ; 
aad  LON  LEVU.  10; 


FS  Machine  Code  Insertions 

The  reader  should  be  familiar  with  the  code  generatioa  strategy  and  the  80x86  instruction  set  to 
fully  benefit  from  this  section. 

As  described  in  chapter  13.8  of  the  ARM  (DoD  83]  it  is  possible  to  write  piocedutes  containing 
(Hily  code  statements  using  the  preddtaied  package  MACHINE.COK.  The  pKfcage 
MACHINE.COOE  defines  the  ^pe  MAClflNE.INSrRU^ON  which,  used  u  a  record  aggregate, 
defines  a  machine  code  insertion.  The  following  sections  list  the  type  MACHlNE_INSTRUCnON 
and  types  on  which  it  depends,  give  the  restrictioos.  and  show  an  examine  of  how  to  use  the 
packi^  MACHINE_CODE. 
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F^.l  Prcdefintd  Types  Ibr  Machine  Code  Insertions 

The  foUowhig  types  are  delined  for  use  when  making  machine  code  insettions  (their  type 
declacaiions  are  given  on  the  following  pages): 

type  opcode.type 
type  operand.i^ 
type  register.!:^ 
ty^  segmem_register 
type  macliine_insttuction 

The  type  REGISTER.TYPE  defines  regisrers.  The  registen  STi  describe  registers  on  the  floating 
stack.  (ST  is  the  top  of  the  floating  stack). 

The  type  MACHINE_INSTRUCnON  is  a  discriminant  record  type  with  which  every  kind  of 
instruction  rsn  be  described.  Symbolic  nmnes  may  be  used  in  the  foim 

name 'ADDRESS 


Restrictions  as  to  symbolic  names  can  be  found  in  section  F.9.2. 

It  should  be  mentioned  that  addresses  are  specified  as  80386/80486  addresses.  In  case  of  other 
targets,  the  scale  factor  should  be  set  to  "sc^.r. 


typ«  epced«_typ*  is  ( 

—  tdac  iMtnietloaa : 


a  AAA, 
CALLM, 

B_AAD, 

a^AAM, 

‘a  CIN, 

a  CLC, 

a  CLO, 

a'DAS, 

a^OEC, 

a"orv. 

b"iiito. 

a“lRET, 

a'jA. 

a^JS, 

a^JOE, 

a'jL. 

a'jliE, 

B~JtR:, 

a  JMQE. 

a  JO, 

a“jp. 

a.JPE, 

m”  Its. 

a  LEA, 

a_LOCX, 

LOOPNE, 

a  lO^Z, 

‘a  LOOPZ, 

a  MOV, 

a^MOVS. 

a"POP, 

a“popr. 

a^POSE, 

a^REP, 

a~REPE, 

a  REPME 

m'SAL, 

a~SAR, 

a^SEL, 

m^STOS, 

a'sCE, 

a  TEST, 

•  AA5,  •  A0C. 


■_ADD,  ■  MD, 


a  CALL, 


I  CLS.  a  CMC, 
riLT,  a”tDXV. 

I'JAC.  a^n# 

I  nt.  a" JRA, 
I.JML,  a^timJC. 

I  jvo.  wTjs, 

•LOOS.  a~LOOV. 


a  09,  a  CWS, 
a“mOL,  a"ni. 
a  JBC,  a  JC, 
a^JHAK.  wTm, 
a  JMO,  a  jm, 
a  JZ,  a~JW. 

tTuoon, " 


a  cm,  aOA 
a'lNC,  aac 
a.JCXZ,  iTx 
a  jms#  aiJC 
a  Jtu.  iTjil 
a_LABr,  lUOL 


I  mu.  a  Nts. 
■_pusar,  wTticu, 

■  RET,  a  RSTV, 
rsBR,  a^SM. 
rNAZi.  a^xcae. 


a  nor,  a  MOT, 
a_RCR, 
a  RETM. 
a~SCA3,  a  STC, 
a~XLAT,  a~XOR, 


a  OR, 

a  ROL.  tTtm., 
wTnrtm, " 

a  STB, 


->  •0t7/t01S7/S0287  riMtln«  Potnc  Preea 


i«r  tMCtueeleaa: 


a  PAIS, 

a  PADD, 

a  PADOO, 

a  PADDP. 

a  PELO,  a  PESTP, 

a  PCES, 

a^mCLEX, 

mjrcOM, 

a'PCOm, 

a'pcOW, 

B~PCai»0,  a  PCOWP, 

a'pDECSTP, 

a'roiv. 

a~POZVD, 

a~POIVP, 

a^POrVE, 

a~POZVRD,  a'PBlVEP, 

a'rPRZE, 

a^riABO, 

a~PIAOOO, 

a'PICOM, 

wTnoam 

a  PXCOW,  a  PXeeWD,  a  PX9XV, 

a"riBIVD, 

a“piDlVR, 

a~PZOIVRO, 

wTrito. 

a  PXUO.B  PXLOL, 

a  PXMOL, 

a"riMOlO, 

m'rmcsTr, 

a'PEZEXT, 

a  PZST, 

a  PZSTO,a~PXSTP, 

a~PXETPO. 

a  rXSTPL, 

tTrism, 

a'pZSOBO, 

a  PXSOER 

a  PXSBERor  a  PIO. 

B~PUO, 

a  FLOCN, 

a^rUEMV, 

aJPLOLa, 

a^PUIM 

a_PlDL2E,  a  PIOL2T,  a.PLOPX, 

a^FLOZ, 

a^PISl, 

a" mOL, 

a~rM0U. 

a  PMOLP.  a  PEOP, 

a  PPATAM. 

a.FPREM, 

a'pPTAM, 

m~nmojMT, 

a~PESTOR 

.  ~  a  PEAVE.a  PECALS, 

a'pEBTPM, 

a  rSQRT, 

b“pst. 

b"pstd. 

a'PETCE, 

a  rSXEKV,  a  PSTP, 

a  PSTPD, 

m~rS7SII, 

a~ PSTSNAX, 

a'PEOE, 

a'PEOlO, 

a'pEOEP.  a  PEOEE, 

a  PSOERO, 

a^rSOERP, 

a~PT«. 

a^PMAZT. 

a^PXAM, 

ajrXCE.  a  rXTEACX,  a  PtLZX, 

a'rTLZXPl, 

a~P2EMl. 

->  MISC/SOSSC/MSSC  tnatsuettona : 

->  Neetea  Chat  aoaa  taaadlata  vanloas  ot  tha  MM 
->  iastnietlana  anlp  axlat  an  tbaaa  caspaea 
-*■  (ahirta,ratataa,paah,lMl,  ...I 


a  aooro,  a  CLTS,  a  Bfin, 

a"lIBT,  a“LSL,  a"00T8, 


a  ZMS,  a  LAR,  a  LEAVE.  a  LOn, 

a~POPA.  a_POSaA,a_SaDT.  b_SIOT, 


234 


DACS-80x86  User’s  Gukk 
Imptanoitaikio-Dependent  Qanaeristics 


mJMi..  ■_UOT. 

■  X*  bit  aiwaya. . . 
a.SUT.  ■_a<SW.  a_STR. 

—  th«  SOiSC  spaeifle  Inacmctlana: 


■  SBXA, 

■  SCTBB, 

■  sen. 

■  sens. 

■  SSXC. 

■_sxxa. 

■.SCTOK, 

■''SRL, 

■_SRIX. 

■'’ssnx. 

mjunm. 

B_SSmB, 

■  setMc, 

■_SB1IB. 

■~BBTM. 

m  scnm. 
a  seem. 

■  axxm, 

■  BSTO, 

■  SRIILB. 

■  sen. 

■~BBaO. 

■~BBtn. 

■~nx», 

■'’sexto. 

s_SEtX. 

a_S«. 

■  Bsr, 

•"irs. 

■  BBB. 

■'’lss. 

■_Bt. 

■_LBB. 

■jBte. 

■jetsx 

X  WVCB. 

■  HOVBB, 

■'mvn. 

■  BSU. 

mjUK, 

—  tba  toss?  apaeifle  iaatzvetloaa : 


■  roecM. 
■^rsxacos. 

—  byta/N 

—  not  dadaei 


ttf/dnorct  variaata  (to  ba 
ibla  fteai  eaotaxt) : 


uaad.  whan 


■JtfiCB. 

■  ASCN, 

■  AOCO, 

■  AMDB, 

■~AMDM, 

■'ambo. 

■_BtCO. 

■  BT1W, 

■’’axm. 

■  CMDB, 

tTcmm, 

mJSQ. 

■  CSVSB, 

■~CMtSM, 

■  emso. 

■_orwB, 

■“divii. 

■~OIVD, 

■  IMOU, 

■~IMOUI, 

■~ZMDU. 

■_XIISB. 

■~’XMSH. 

■  XMSO, 

■  MOVB, 

■~HOVN, 

a''MOVD, 

■_MOVS», 

■~MOVSXH, 

■"hovxxb 

■  HDLO, 

■~iiBeM, 

■_IIOTO, 

■"oBa. 

■~OBH. 

■  OOTSO, 

■~tOf1l, 

■~>an. 

■_BeL«. 

■~BeLO, 

■’’BCBa, 

■  BOLN, 

■'‘mu. 

■'‘aOBB, 

■.SAM, 

■  SAU, 

■  SABS, 

■.sauf. 

■  SatDM, 

■  SBBB. 

■.SBBW. 

■.SBBO. 

■  SCASB. 

■.STOSW, 

■  SXQSO, 

■  SOBB. 

■.TtStW, 

■  TSSTO, 

■"XOBB, 

■  OATAH, 

■’’OAXAD, 

■  BTSW, 


•JkSDH, 
m  ITO. 
■  BTSO, 


■.Bn, 


■.rsn,  ■.Fcos, 


■  hOOO, 

■Ibtcm, 


OBCB. 
"ZBXVB.  ■ 
“iMCB. 
~LS:SB,  ■ 
“sicva.  o' 
“ncvzxw, ■ 


■  OBCM, 

lOXVW, 

'  ■  ZMCN. 
tOOBN, 


OKD. 

"bosbm,  ■ 
"bom. 


■jms. 

■  non, 

■  OOTSB.a 
tOBBD,  ■ 


■  CWD, 
■"DeCD, 

xoxn, 

■  zbce, 
.Lfloao, 
HOVSD, 

■  MDUf, 


OOtSb, 

'bclb. 


a  BBKM. 
a  sam. 
a.BCAJN.  ■ 
a  SOBN, 
a  XORN. 


■  BOBO. 
■_SMS. 


■_saui, 


BCBSD.  ■ 

■  son, 

m  XOBD, 


■  TBBS*. 

■.oaxM, 


—  Spaeial  ' loatauettena' ; 

—  Boa7  taav  raai  load/atora_aad_pop; 


■_labal,  a.taaat, 

■_rU)T,  •_rSt»T>; 


pra«Ma  papa; 

typa  oparand_typa  la  (  aona, 

laaMeiata, 

cagiatac, 
addtaaa, 
ayacaa.addrotca , 

naaM,~ 

tagiatar_1— arttita. 


raglatar.taglatac, 

raglatar.addraaa. 


a«ldsaaa_ea«iatar. 


no  opocaada 

—  ono  inaotfiato  opocand 

—  ono  cogiator  oporaad 

—  ono  addroaa  opotand 

—  ono  'addxaaa  opocand 
~  CBXO.  naaa 

—  two  oparanda  : 

—  daatination  la 

—  cagiatac 

••  aoocea  ia  iHadiata 
~  two  cagiatac  opocaada 
'  two  opocaada  : 

—  daatinMioa  ia 

—  cagiatac 

—  aoucea  ia  addcaaa 

—  two  opocaada  : 


235 


DACS-80K86  User’s  CHikk 
IiiifiieaBeni«ioa>Depenlem  Qisnoeiisiks 


r««tat«c_ayst«i_*ddrMa  > 

ayatw_addr«aa_r««iacar. 

addraaa_fai1Xata. 

ayataai_a4drMa_UMdlaea, 

lawirtlaf_taylatac. 

t—aitlata_lwiartlata. 

ra«laear_ra«tat«r_laBadl«ta, 

*  ra9latar_addraaa_l  — aiilata. 
ragiaca^ayataat*addraaa_taaiafliata. 
addraaa_^latar_tiadlata. 

ayataai_addraaa_ra9latat^l—adlata 


—  daattaatloa  la 
••  addMaa 

—  aoarea  la  cayiatar 

—  two  opatanda  : 

—  daaciaaclaa  la 

—  raglacar 

—  aoiicea  la  ‘addsaaa 

—  ctfo  oparanda  : 

—  daatlaaclaa  la 

—  'addsaaa 

—  aaarea  la  caylatac 
—  Caa  aparaada  : 

—  daaciaatlaa  la 

—  addsaaa 

—  aaasea  la  laaadlata 

—  taa  apasaada  : 

->  daatlaaclaa  la 

->  'addsaaa 

—  aaasea  la  taaadlaca 

—  aaly  allawad  fas  OOT 
••  past  la  laaadlata 

—  aaasea  la  saglacas 

—  aaly  allawad  fas 
..  ayflF 

—  allaaad  fas  XHDLlaN, 

—  snoiaa,  snctaa 
••  allaaad  fas  IMDllaa 

allaaad  fas  XMOLlaa 

~  allaaad  fas  sniOlaM, 

SILOlaa 

—  allaaad  fas  snoiaM, 

—  snoiaa 


type  radlacas  typa  la  (AX,  CX,  OX,  SX,  St,  It,  SI,  OZ,  —  aasd  saga 
AA,  CL,  OL,  SL.  AS,  CS,  01,  H,  byta  saga 
iAX,xex.cox,nx,xst,cu,esx,eoz,->  ^sd  saga 
ts,  CS,  SS,  os,  rs,  os,  aalaetosa 

BX_S1,  BX.OZ,  St.SZ,  It.oz,  t0S</S01S</S02SS  eeaOlaaClaaa 

StT  sfl,  its,  STS,  —  flaatlag  saglatasa  (stack) 

ST4,  STS,  STS,  ST7, 

nil); 

••  tlia  axeandad  saglatasa  (KAX  . .  KOI)  plus  rs  and  SS  are  only 
—  allaaad  In  SOSSC  casgacs 

type  seala_cypa  la  (scala_l,  aeala^I,  seala_4,  seala_SI; 
subtype  aaelilna^acclng  la  acting (1.  .100) ; 


psagaw  paga; 

type  aaelilna_lnacsuetlaa  (apasand_klnd  :  epasaad_Cypa)  la 
racasd  ”  ~  ” 

opeeda  :  epcoda_cypa; 

easa  epasaad_klnd  la 
aiMn  tiadlata  » 

iMadlatal  :  intagas;  —  UMdlaCa 


ahan  saglstas  >> 

r_saglscas  :  saglstas^typa;  — 


aaasea  and/as  dastlaaciee 


a  addsaaa  base 


abac  addsaaa  a> 
ajaagaant  :  caglstas_cypa;  — 

■  “  ■  :  saglscas_cypa 

:  saglstas_cypa 
a_addsaas_aeala  :  seala_cypa; 

a~addsass~affsac  :  Intagas; 


aaasea  ond/as  daatlaaclaa 


abac  ayscaa_addcaas  ■> 

aa  addsaaa  :  ayscaa. addsaaa;  — 


daaciaatlaa 
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whan  a«M  ■> 

ii_atrta«  :  MehtM_acrla«;  •>  CMX  «lMtla«ttaM 

whan  rafflatar.lBMdlata  » 

ca*taear_e>paj  —  Uaatiaatlaa 

r_l_laBMtflata  :  tata«ar;  —  aaucea 

whan  ragiatac^ragiacar  •> 

:  raglaear.typa;  —  Uaatiiiaeien 

:  cagiatar_eypa;  —  aauzea 

whan  tagtataE_addraaa  » 

c_a_taglatar_to  :  caqtatac^typa;  —  dMltaatlea 

c_a_aa9Mac  :  gm^attjtypm;  ~  aatirea 

r_a^addraaa_haaa  :  ragiacar  typa; 

r_a_addraaa_liidax  :  tagiatac'typa; 

r_a_aUdraaa_aeala  :  acala  ty^; 

r_a_addraaa_effaat  :  latagac; 

whan  addEaaa_raglatar  •> 

a_r.aa$pant  :  raglatac^typa;  —  daatiaatloa 

4_r_addtaaa_baaa  ;  raglatar^cypa; 

a_r_addcawa_tndax  ;  raglatar" cypa; 

a_E_addraaa_aeala  :  aeala  ty^; 

a_r_addraaa_e£faat  :  tntagar; 

•_f_s«el«tar_£wBi  :  caglatar_typa;  ~  aoutea 

whan  taglatar_ayataai_addraaa  •» 

r_aa_Eagiatar_to  ~  :  taglatar_typa;  —  daatlaatlon 

r_aa_addxaaa  :  ayataa.nddraaa;  ~  aoutea 

whan  ayataa_addtaaa_caglatac  •> 

aa_E_addtoaa  “  :  ayataa.nddraaa;  —  daatlaatlon 

fo*  !  taglatat_typa;  —  aoutea 

whan  addraaa_laaMdlata  •> 

a_l_aa^nt  :  raglatar_typa;  —  daatlnatlon 

'•  raglatat^typa; 
a_l_addraaa_,lndaji  :  taglatat^typa; 

a_l_addtoaa_aeala  :  aeala_tyi^; 

a_l_addtaaa_o££aat  :  latagat: 

a_t^l*adlata  :  latagat;  —  aoutea 

whaa  ayataa_addraaa_laaadlata  » 

aa_l_addtaaa  :  ayataa.addtaaa;  —  daatlaatlon 

aa_l_liwiadlata  :  intagar;  —  aoutea 

whan  laaadlata__raglatar  ■> 

l_r_laBadlata  :  latagat;  --  daatlaatlon 

l_t_ra9l»e*t  :  roglatar_typa;  —  aoutea 

whan  laa»adlata_1aaadlaea  •> 

l_l_lanwdlatal  :  latagat;  —  laaMdlatol 

l_l_laBadlata2  :  latagat;  —  laaMdlataS 

whan  raglatar_raglBtar_laBwdlata  -> 

t_E_l_raglatatI  :  taglatar_typa;  —  daatiaatloa 

:  raglatat  typa;  —  aouteal 

r_r_l_laaiadlata  :  latagat;  —  aouteaS 

whan  raglatat_addraaa_laBMdlata  •■> 

t_a_l_tagiatar  ”  :  taglatar.typa;  —  daatiaatloa 

t_a_l_aagaant  :  taglatar_typa;  —  aouteal 

*’_a_l_aeeraaaj»aaa  :  roglatat_typa; 

r_»_l_addtaaa_lndax  :  taglatoc^typa; 

-_a_l_addtaaa_aeala  :  acala_t]^; 

t_a_l_addtaaajB££aat :  latagat: 

r_i_l_laaiadlata  :  latagat;  ~  aoaceaS 

whan  raglatar_ayataa_addtaaa_laawdlata  » 

r_aa_l_taglatar  7  taglatar_£ypa;  —  daatlaatlon 

•UdtlO  ;  ayataa.addtaaa;  —  aouteal 

r_aa_l_lanadlata  :  latagat;  —  aouteal 
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whMi  4dte— >_r*gl«f  t_t— (II  «f  •> 

~  :  x««laCM.typ*;  —  dMtlMtton 

•_c_l_«ddXMa_bu«  :  nglatar.typa; 

a_c_l_addc«aa_liidax  :  Mgiatar.typa; 

a_.c_l_addrMa_acala  :  aeala_typa; 
a_r3i~addXMa~effaac:  lacagar: 

a_c~l3n«tatat  :  raglatar.typa;  —  awiceal 

a^r_lJLaMcllaea  :  iatavar;  ~  ->  aoutcal 

whan  ayataai_aedzaaa_ratlacar_ljMadlaca  ■> 

aa.^l_adtfrMa  T  ayataa.addcaaa;  —  daatlaation 

aa_t^i^ratlacac  :  ca«iatar_typa;  —  aauteal 

aa_rjt_la*aeiata  :  latagar:  aaataaS 

whan  othaca  •■> 
null; 
and  eaaa: 
aad  raeofd; 

and  a«ehlna  coda; 


F.9  J  Restrictions 

Only  proceduies,  and  not  functions,  may  contain  machine  code  insertions. 

Symbolic  names  in  the  form  x'AODRESS  can  only  be  used  in  the  following  cases: 

1)  X  is  an  object  of  scalar  type  or  access  type  declared  as  an  object,  a  formal  parameter,  or 
by  static  renaming. 

2)  X  is  an  array  with  static  constraints  declared  as  an  objea  (not  as  a  formal  parameter  or  by 
returning). 

3)  X  is  a  record  declared  as  an  objea  (not  a  formal  parameter  or  by  renaming). 


The  m.CALL  can  be  used  with  "name"  to  call  (for)  a  routine. 

Two  opcodes  to  handle  labels  have  been  defined: 

mjabel:  defines  a  label  The  label  number  must  be  in  the  range  1  <>  x  <>  999  and  is  put 

in  the  offset  field  in  the  first  operand  of  the  MACHINE.INSTRUCTION. 

m.reset:  used  to  enable  use  of  mote  than  999  labris.  The  label  number  after  a  m_RESET 

must  be  in  the  range  lo  x  <»  999.  To  avoid  errors  you  must  make  sure  that  all 
used  labels  have  been  defined  before  a  reset,  since  the  reset  operation  clears  all  used 
labels. 

All  floating  instructions  have  at  most  one  operand  which  can  be  any  of  the  following: 

•  a  memory  address 

•  a  register  or  an  immediate  value 

•  an  entry  in  the  fkuiing  stack 
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J  Examples 

The  following  section  contains  examples  of  bow  to  use  the  machine  code  insertions  md  lists  the 
generated  code. 


F.9.4  Example  Using  Labds 

The  following  assembler  code  can  be  described  by  machine  code  insertions  as  shown: 

MOV  ^kX.^ 

HOV  CX,4 
CW  AX.CX 
J6  1 
JE  2 
HOV  CX.AX 
1:  UD  AX.CX 
2;  HOV  SS:  (aSt’DX],  AX 

p«ekA«*  ■»ii)l«_HC  la 

preeadux*  t«at_lAb«la; 
pragma  tnllna  Ttaat_lalMlsl  ; 

and  axampla_HC; 

wlth  HACinn_COOC;  usa  MACXXIIE_CaDC; 
paekaga  body~axaaipla_MC  la  ~ 


proeaduca  eaat_latoalj  la 
bagln 

KACSniE  nsntOCTXOM' (raglacar  lawadlata.  mjiov.  AX.  t); 
HACBXME'rsiSTROeTXOM' (raglatar  lamadlaea.  ajNOV.  ex.  4); 
HACXXtie'xiiSTiiocrxoN' (ragiatar  raglatac.  s_CM»,  AX.  CXI; 
MAOlxarnSTPOCrXOH' (Uaaadlata.  m_X,  X); 

MACXXMX'XMSTROCXXOR' (UHMdlata,  s_JX.  2); 

macbxne'xhstroctxoh' (caglatar_ragiatac.  sjiov,  cx.  AXi; 
hacbxne'xmstboctxon' (lamadiata,  s_labal.  li; 

macbxme^ZRSTIWCTXON' (raglacar_caglacar.  a_ADD.  ax.  CXI; 
MACBXMt^XMSTHOCTXOW  (lamadlata,  m  labal,  2); 
MACBXHE~XMSntOC7XOM'  (addraaa  raglacar.  ■  MOV.  ss.  W. 

OX.  aeala  X.  0.  AX); 


and  caac_Iabala; 
and  aximpla_HC; 


F.9J  Advanced  Topics 

This  section  describes  some  of  the  more  intricate  details  of  the  workings  of  the  machine 
code  insertion  facility.  Special  attention  is  paid  to  the  way  the  Ada  otgecis  arc  referenced  in 
the  machine  code  body,  and  various  alternatives  are  showa 
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F.9J.1  Address  Spcdflcations 

Package  MACHINE.CODE  provides  two  alternative  ways  of  specifying  an  address  for  an 
instruction.  The  first  way  is  referred  to  as  SYSTEM.AODRESS  and  the  parameter  associated 
this  one  must  be  specified  via  OBJECT' ADDRESS  in  the  actual  MACHINE.CODE  insertion.  The 
second  way  closely  relates  to  the  addressing  which  the  80x86  machines  employ:  an  address  has 
the  general  form 

segmem:[base-»>index*scale-K>ff5etl 

The  ADDRESS  type  expects  the  machine  insertion  to  contain  values  for  ALL  these  fields.  The 
default  value  NIL  for  segment,  base,  and  index  may  be  selected  (however,  if  base  is  NIL.  so 
should  index  be).  Scale  MUST  always  be  specified  as  scale.!,  scale.2.  scale.4.  or  scale.8.  For 
16  bit  targets.  scale.I  is  the  only  legal  scale  choice.  The  offset  value  must  be  in  the  range  of 
-32768  ..  32767. 


F.9JJ  Referencing  Procedure  Parameters 

The  parameters  of  the  procedure  that  consists  of  machine  code  insertions  may  be 
referenced  by  the  machine  insertions  using  the  SYSTEM.ADDRESS  or  ADDRESS  formats 
explained  above.  However,  there  is  a  great  difference  in  the  way  in  which  they  may  be  specified; 
whether  the  procedure  is  specified  as  INLINE  or  not. 

INLINE  machine  insertions  can  deal  with  the  parameters  (and  other  visible  variables)  using  the 
SYSTEM.ADDRESS  form.  This  will  be  dealt  with  correctly  even  if  the  actual  values  are 
constants.  Using  the  ADDRESS  form  in  this  context  will  be  the  user's  responsibility  since  the 
user  obviously  attempts  to  address  using  register  values  obtained  via  other  machine  insertions.  It 
is  in  general  not  possible  to  load  the  address  of  a  parameter  because  an  'address’  is  a  two 
component  structure  (selector  and  offset),  and  the  only  instruction  to  load  an  immediate  address 
is  the  LEA.  which  will  only  give  the  offset.  If  coding  lerpiites  access  to  addresses  like  this,  one 
cannot  INLINE  expand  the  machine  insertions.  Care  should  be  taken  vidth  references  to  objects 
outside  the  current  block  since  the  code  generator  in  order  to  calculate  the  proper  frame  value 
(using  the  display  in  each  frame)  will  apply  extra  registers.  The  parameter  addresses  will, 
however,  be  calculated  at  the  entry  to  the  INLINE  expanded  routine  to  minimize  this  problem. 
INLINE  expanded  routines  should  NOT  employ  any  RET  instructions. 

Pure  procedure  machine  insertions  need  to  know  the  layout  of  the  parameters  presented  to.  in  this 
case,  the  caUed  procedure.  In  particular,  careful  knowledge  about  the  way  parameters  are  passed 
is  required  to  achieve  a  succesful  machine  procedure.  When  not  INLINE  a  block  is  created  around 
the  call  which  allows  addressing  of  parameters,  and  code  for  exiting  the  procedure  is  also 
automatic. 

The  user  takes  over  the  responsibility  for  correa  parameter  addressing.  The  rules  of  Ada 
procedure  calls  must  be  followed.  The  calling  conventions  are  summarized  below. 
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Parameter  Transfer 

It  may  be  a  problem  to  figure  out  the  conea  number  of  words  which  the  paiameteis  up  on 
the  stack  (the  x  value).  The  following  is  a  short  description  of  the  transfer  method; 

INTEGER  types  take  up  at  least  1  storage  unit  32  bit  integer  types  take  up  2  words,  and  64  bit 
integer  types  take  up  4  words.  In  32  bit  targets.  16  bit  itueger  types  take  up  2  words  the  low 
word  being  the  value  and  the  high  word  being  an  alignment  word.  TASKs  are  transferred  as 
INTEGER. 

ENUMERATION  types  take  up  as  16  bit  INTEGER  types  (see  above). 

FLOAT  types  take  up  2  words  for  32  bit  floats  and  4  words  for  64  bit  floats. 

ACCESS  types  are  considered  scalar  values  and  consist  of  a  16  bit  segmem  value  and  a  16  or 
32  bit  offset  value.  When  32  bit  offset  value,  the  segmem  value  takes  up  2  words  the  high  word 
being  the  aligment  word.  The  offset  wotd(s)  are  the  lowest,  and  the  segmem  word(s)  are  the 
highest. 

RECORD  types  ate  always  transferred  by  address.  A  record  is  never  a  scalar  value  (so  no 
post-procedure  action  is  carried  out  when  the  record  parameter  is  OUT  or  IN  OUT).  The 
reptesemation  is  as  for  ACCESS  types. 

ARRAY  values  ate  transferred  as  one  or  two  ACCESS  values.  If  the  array  is  cmistrained.  only 
the  array  data  address  is  transferred  in  the  same  manner  as  an  ACCESS  value.  If  the  array  is 
unconstrained  below,  the  data  address  will  be  pushed  by  the  address  of  the  constraint  In  this 
case,  the  two  ACCESS  values  will  NOT  have  any  alignmem  words  in  32  bit  targets. 

Packed  ARRAY  values  (e.g.  STRING  types)  are  transferred  as  ARRAY  valu.  .  th  the  addition 
of  an  INTEGER  bit  ofl^set  as  the  highest  word(s): 

+H;  Brr.OFFSET 
+L:  DATA.ADDRESS 

+0:  CONSTRAlNT_ADDRESS  -  may  be  missing 

The  values  L  and  H  depend  on  the  ptesetKe/absence  of  the  constraim  address  and  the  sizes  of 
constraint  and  dau  addresses. 

In  the  two  latter  cases,  the  form  parameter’addtess  will  always  yield  the  address  of  the  data.  If 
access  is  required  to  constraim  or  bit  offset,  the  instmetions  must  use  the  ADDRESS  form. 


F.9  J.4  Example 

A  small  example  is  shown  below  (16  bit  target): 

procedure  unsigned.add 

(opi  :  in  integer 

op2  :  in  integer, 

res  :  out  itueger); 
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Notice  th«  nudane  subfxoffams  cannot  be  fimctions. 
The  penmeten  take  up: 


opl 

:  integer 

1  word 

op2 

:  integer 

I  word 

res 

:  integer 

1  word 

Total 

; 

3  words 

‘The  body  of  the  procedure  might  then  be  the  fDOowing  assuming  that  the  procedure  is 
defined  at  ouiennost  package 


prae«tfut«  uMlpnad  add 

<0^  :  la  latagar; 

op2  :  la  latapar: 

raa  oat  latayarl  la 


bagla 

praqaa  abacraet_aeoda_laaartloaa  <tntal  ; 
aa^laaat'  (aa_erMta_ileek.  1, 1.0,0, 0) ;  — 

aa'taacr*  <aa3Bad_of~daelpart, 0, 0, 0, 0, 01  ; 
pra^aa  abstraet_a«ote_iasattleaa(ralaa>; 


a  ■  3.  y  ■  1 


a«eataa_laattuetloa'  ( ra«latac_ayataai_addtaaa. 

"  axT  opl'aSdxaaat; 

■aeblaa^laatrueciaa'  (raplacac^ayataB^addtaaa, 

axT  op2‘ addtaaa) 
■aehlaa_iaatruetloa‘  (liadlata, 
aMchlaa^laatcuecioa'  (lapMdlata. 
aaeblaa^laatruetlaa' (laaadlata, 
•aeaiaa^laatruetioa'  (aystaa_addaaaa_ra9lstas, 

saa' addtaaa.  ax>; 


a  NOV, 


ajkOO, 
a.JUC,  l> 

■^xnr,  S) 
■  labal.l) 
a.MOV, 


pta«da  abatraet jteada_laaattlaaa (traa) ; 
aa.laaer'  (aa.Bxlt.aabpt«ai.  0,0,0.  all.atp,  all.atp) ;  <3 ) 

aa^iaaer' (aa_Sac_bloek_la«al,0,0,0,0.0l;  —  y-1  -  0 

ptapM  abatraet_aeoda_laaactloaa<falaa); 
and  uaal9nad_add,- 


A  routine  of  this  complexity  is  a  candidate  for  INLINE  expansion.  In  this  case,  no  changes  to  the 
above  'machinejnstniction'  statements  are  required.  Please  notice  that  there  is  a  difference  between 
a(k'^<'ing  record  fields  when  the  routine  is  INLINE  and  when  it  is  not: 


type  rec  is 

record 

low 

:  integer; 

high 

end  record: 

:  integer. 

procedure  add_32  is 

(opl 

:  in  integen 

op2 

:  in  Inqer. 

res 

:  out  rec); 

The  parameteis  take  up  1  1  >  2  words  ■  4  words.  The  RES  parameter  wiD  be 

addressed  directly  when  INLINE  expanded,  Le.  it  is  possible  to  write: 
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macliine_instniction‘(sysiein_additss_iegister.  m_MOV. 

res’addiess,  AX): 

This  would,  in  the  not  DMUNEO  version,  be  the  same  as  updating  that  place  on  the  stack  where 
the  address  of  RES  is  placed.  In  this  case,  the  insenion  must  read: 

machineJnstniction'(register.system_address.  m.LES, 

SI.  res'address): 

~  LES  SI.IBP+...] 

inachineJnstniction’(address_register.  m_MOV. 

ES.  SI.  nU.  scale.I.  0.  AX); 

-  MOV  ES:[Sl40]>^X 


As  may  be  seen,  great  care  must  be  taken  to  ensure  coma  machine  code  insertions.  A  help 
could  be  to  first  write  the  routine  in  Ada.  then  disassemble  to  see  the  involved  addressings,  and 
finally  write  the  machine  procedure  using  the  coUeaed  knowledge. 

Please  notice  that  INLINED  machine  insertions  also  generate  code  for  the  procure  itself.  This 
code  will  be  removed  when  the  •nocheck  option  is  applied  to  the  compilation.  Also  not 
INUNED  procedures  using  the  AA.INSTR  insertion,  which  is  explained  above,  will  automatically 
get  a  storage.check  call  (as  do  all  Ada  subprograms).  On  top  of  that.  8  bytes  are  sa  aside  in  the 
created  frame,  which  may  freely  be  used  by  the  routine  as  temporary  space.  The  8  bytes  are 
located  just  below  the  display  vector  of  the  f^e  (from  SP  and  up).  The  storage.check  call  will 
not  be  generated  when  the  compiler  is  invoked  vnth  •nochcck. 

The  user  also  has  the  option  NOT  to  create  any  blocks  at  all  but  then  he  should  be  certain  that 
the  renim  horn  the  roudne  is  made  in  the  proper  way  (use  the  RETP  instrucnon  (return  and  pop) 
or  the  RET).  Again  it  will  help  first  to  do  an  Ada  version  and  see  what  the  compQer  expects  to 
be  done. 

Symbolic  fixups  are  possible  in  certain  instrucdons.  With  these  you  may  build  ’symbolic’ 
insmictions  byte  for  byte.  The  instructions  involved  all  require  the  operand  type  NAME  (Uke  used 
with  CALL),  and  the  itueipretation  is  the  following; 

(name.  m.DATAD.  "MYNAME”)  a  full  virtual  address  (offret  and  sdector)  of  the 

symbol  MYNAME  (no  additional  ofCsa  is  possible). 

(name.  m.DATAW.  "MYNAME")  the  offsa  part  of  the  symbol  MYNAME  (no  addidonal 

offret  is  possiUe). 

(name.  m.DATAB.  "MYNAME")  the  selector  value  of  symbd  MYNAME 

In  inlined  machirre  instructions  it  may  be  a  problem  to  obtain  the  address  of  a  parameter  (rather 
than  the  value).  The  LEA  instruction  may  be  used  to  get  the  offsa  pan,  but  now  the  following 
form  allows  a  way  to  load  a  selector  value  as  well: 

(system.address,  LES.  param ’address)  ES  is  loaded  with  the  sdecror  of  PARAM.  If  diis 

selector  was  e.g.  SS,  it  would  be  pushed  and  popped 
into  ES.  LES  may  be  substiitited  for  LFS  and  LOS 
fbr  80386. 
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F.10  Packafe  Tasktypcs 

The  TaskTypes  packages  defines  ihe  TaskConm^lodc  type.  This  dau  stnictuie  ooukl  be  usefiil 
in  debugging  a  tasking  program.  The  fdlowing  package  Tasktypes  n  for  ail  DACS-80x86  except 
for  DACS-80386PM/DACS-^0486PM. 


with  SyaCMi; 


pacliaga  TukTypaa  is 

svbcyp*  oeSs«C  is  Systaa.OnslfasMocd; 
siibtyp*  aioekXU  is  Systaa.OsaifBsdHesd; 


typ« 

typs 

typs 

typs 

typs 

for 

typs 


TMkXatiy  la  a««  ayatsa.OnslpMdHscd; 

■acsyZndax  la  amm  ayatsat.OnalfiMdNssd; 

Altarnatlvaze  la  ama  Syata«.OMlpnaMotd; 

Ticks  is  ncM  syscaai.OHetd; 

Sool  Is  scit  Poelasa; 

■oel'alsc  osc  S.* 

OSstg  Is  as«  syscaai.OnslpncdNecd; 


cyps  TsskStscs  Is  (Znltlsl. 

—  Tbs  task  la  erssead,  but  setlva'lon 
—  has  ace  atsrtsd  ysc. 


Xapspsd, 

~  Tbs  cask  baa  callad  an  antsy,  and  tbs 
••  call  la  now  aeeapcad,  la.  tha  randasvoas 
~  la  la  profrasa. 

Roanlap, 

—  Coasts  all  otbac  acatas. 

Oalayad, 

Tba  cask  awaiea  a  tlaMout  to  asplra. 
taccyCalllaTTlaad, 

••  Tba  cask  has  callad  an  antsy  wblch 
••  la  net  yat  aeeaptsd. 

Bacsycallla«aooondlcianal> 

~  Tba  task  has  callad  an  antsy  unconditionally, 
which  la  not  yat  aeeaptsd. 

SalaetlnsTlawd. 

—  Tha  task  la  waiting  la  a  sslact  scacaaanc 
with  an  span  daisy  altasnatlwa. 

SalactlagOnceadlcianal. 

Tba  task  waits  in  a  salaet  statanant 
ancissly  with  aeeapc  ststasMacs. 

SalaeciagTaxBlnabla, 

—  Tha  cask  waits  in  a  salaet  stacaMnt 
~  with  an  open  tasadnata  alcacaaciva. 

becapciag, 

—  Tha  cask  waits  la  an  aeeapt  stacasMnt. 
Pynehsnnlslag, 

—  Tba  cask  waits  la  an  aeeapc  statoMat 

—  with  no  acatasMne  list. 

Caaiplacod. 

—  Tha  cask  has  eeavlatad  tha  aaaeutlan  of 

—  Its  stataaMac  Use.  bat  not  all  dapandant 

—  tasks  asa  casmlaacad. 

Tacadaacad  i; 

—  Tba  cask  sad  all  its  daseaadaats 

—  asa  tacdiaacad. 
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for  TookStoeo  oso  (Zatttol  ■>  ISSOO*  , 

SiifOfod  ->  ISMS*  , 

Itaumlnf  »  IStlO*  , 

OoXoyod  »  , 

EatxyColliofTlJMd  <■>  ICSSOS  . 
BatcyCalllaifOoeaodltloiiol  »  1M2B*  , 
Soloetia«XlMd  ->  1SS31*  . 
SoloetiafOoeoaditloMl  »  1SS3M  . 
SoloetiayToaiiaablo  »  , 

Aeeoptliie  ■>  1SS4*«  . 

Syoehronitljif  •>  1S4S3S  , 

Coaplocod  »  ISSSCS  . 
tooilMCOd  »  ISSMSI; 

for  ToskStoco' riio  uoo  S; 

cypo  TookTypoDooerlptor  la 
roeord 

priority  :  SyatoM.Srlorlty: 

ottcry  eoont  :  OZoep; 

bloek_ld  :  lloekXd; 

flrat~o«n_oddroaa  :  Syatoo.Mdroaa; 

■o<lalo_inoi^r  :  OXacp; 

oatryJaiMbor  :  OZatp; 

eodo^oddroaa  :  Syatoa.Mdroaa; 

ataek^alao  :  Syacoa.IMord: 

dueay'*  :  latopor; 

ataek_aa9BOoe_alxo:  OXatp; 
oad  roeord;  " 

typo  AceToakTypoPoacrlptor  la  aeeoaa  TaakTypoOoaerlptor: 

typo  HtXSavoAroo  la  orray<1..4S)  of  syatoa.OaalgaodMord; 

cypo  riogatypo  la 
roeord 

■SXriog  :  Bool; 

Xatomptriog  ;  Bool; 

oad  roeord; 

pragaui  poek(rio«aTypol ; 

typo  StatoaSypo  la 
roeord 

atato  :  taakstato; 

la^abaoraal  :  Bool; 

la_aetlvatod  :  Bool; 

falluro  :  Bool; 

oad  roeord; 

pragea  paekdtataaTypol; 

typo  ACr_typo  la 
roeord 

bp  :  Offaot; 

addz  :  Syatoai.Addroaa; 

oad  roeord; 

pragaw  paek(BCrjtypo) ; 
pragaa  pago; 

typo  TaakCoatrelBloek  la 
roeord 

aoai  :  Syatoa.Soaapboro; 

laMoaltor  :  latogor; 

Delay  goaiio  haadllag 

daoKt  ;  Syataa.TaakVaioo  ; 

dprov  :  Syatoa.TaakValna  ; 

ddolay  :  Tleka  ; 

—  Saved  roglatora 

SB  :  syatoa.OaalgaodNord  : 
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n  :  OffMC  ; 

—  HmUt  haiiUXtav 

OMt  :  Sy*t«a.TMkV«lM  I 

~  SaaMphoc* 

MMMxe  :  SyatMi.TMkVaXiM  ; 


—  trlorlcy  fialda 

prlemy  :  tyatMi.  Priority; 

Mvo«l_prtority  :  PyatM.Priorlty; 

—  mocollooMOM  Ciolda 


tlM_alieo  :  ayataa.OMlpBoUSord; 

rioffa  :  flapatypo; 

SaadyCoimt  :  tyataa.Mard; 

—  Stack  Spoetrieatlea 

ataek_atart  :  otfaot; 

staek_aad  :  offaat; 

—  Stata  eialda 

atatoa  :  StataaTypa; 

'■*  Aetlvatlon  haadllnp  (lalda 


activator 

aet_chain 

aoM^ehain 

iio_not_aet 

aet_bloek 


Syatao . Taakvaiuo; 
Syataai .  Taakvaiuo; 
Syataa . TaakValuo; 
Syataa.Mord; 
aioekXd; 


—  Accept  qooiia  iialda 


partner  :  syataa.TaakVaiuo; 

noatjMttoor  :  Syttaa.TaakVaiua; 

—  entry  ^moo  fiolda 

nont^eallar  :  Syatao. TaakVaivo; 

Rondarvooa  Clalda 


eallod_taak 

laAayacf 
taak_aatcy 
antty_iadoa 
aatry~aasoe 
eall,^raoa 
alt.id 
aaep^id 

>  Dapaodooey  fiolda 

patoat_taak 

paront^block 

ehild^taak 

aoat_ehild 

flrat_ebild 

provj^ld 

ekild_aet 

bloek~aet 

toradaatod  taak: 


:  Syatao. TaakValuo; 
iatapor; 

:  TaakSatcy; 

:  CatxyZadoa; 

:  Syatao.Addsoaa; 

;  Syatao.Addsoaa; 

:  AltamacivoZd; 
Syatao. BaeaptiooZd; 


Syatao . TaakValoo; 
SlockZd; 

Syatao. Taakvaloa; 
Syatao .  SaakValoa ; 
Syatao. SaakValoa; 
Syatao. taakValoo; 
Syatao. Hard; 
Syatao. word; 
Syatao. TaakValoo; 


Abortion  bandlinp  fiolda 
busy  :  Syatao. NOrd; 
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—  JwxlllMy  Sialds 

ttd  :  AeeTMktypaOMeriptoc; 

rinte«li*r  :  SyatM.TMkVAlu*.- 

—  muftlM  SystM  flalda 

ACT  :  terjtyf;  —  ef.  OMr'a  «ulda  •.4.2 

•Orirac  :  Zatagac;  —  Only  oand  la  IM 

Saaricst  :  Sat«9nr:  •-  Only  «a*d  la  IMS 

TBloeklnsTaak  :  Syacaa.tMkValun;  —  Oaly  wand  la  IMS 

VBlaeklagTaak  :  SyaeaM.TMkValiM;  —  Only  nand  la  SHS 

eollaetlon  :  Syacaa.kddtnaa; 
pareteion  ;  Zata«nr; 

taakCtMekUalt  :  OfSant;  ~  to  aaaiiM  tallna  atnca«n  ehnek 

butSxeapCloa  :  Syacaa.ONoxd;  2  *  IS  bita 

SaandMakddr  :  OfSant;  —  to  livtoan  candasvnna'a 

~  HSX  a«a*  ana 

—  Mhaa  tha  applleatlen  la  llakad  with  •ayn.  a  apaeial 

—  aava  axaa  for  tha  Stx  la  allaeatad  at  tha  aaxy  and 
••  oS  avacy  TCB. 

—  la: 

—  eaaa  USX  rtaaant  la 

~  whan  tin  »  NtXaava  :  XSXSavakxaa; 

—  whan  rkLSS  *>  aull; 

—  and  eaaa; 

and  xaeord; 

—  Tha  followlns  la  to  aaaura  that  tha  TCS  haa  tha  axpaetad  alaa: 

TCB_alsa  :  eoaataae  ZMTtOtX  :■  TaakCoateelSloek' alsa  /  •; 

aubtypa  TCB^ok^walua  la  ZIRXOKR  raa«a  134  . .  13S; 

TCX_ek  :  eenataat  TCB_ek_walna  :■  TaakCanteolBloek' alaa  /  S; 

and  SaskTypaa; 


F.ll  RMS  Tasking  (OPTIONAL) 

The  DACS-80x86  systems  may  run  tasking  applications  by  means  of  Rate  Monotonic  Scheduling 
(RMS).  RMS  capability  is  purdtased  optionally,  and  is  thus  not  included  by  defnilt.  Please  contaa 
DDC-I  for  more  information  regarding  RMS  and  your  system.  RMS  allows  the  programmer  to 
guarantee  properties  of  a  tasking  system,  i.e.  that  tasks  will  meet  their  hard  deadlines.  The  RMS 
tasking  is  selected  by  specifying  •rms  to  the  Ada  link  command. 
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